Modular Monoliths • Simon Brown • GOTO 2018
Вставка
- Опубліковано 14 тра 2024
- This presentation was recorded at GOTO Berlin 2018. #gotocon #gotober
gotober.com
Simon Brown - Creator of C4 Software Architecture model and Author of Software Architecture for Developers @simonbrown4821
ABSTRACT
If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices. It's everywhere! For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago "done right". Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you [...]
TIMECODES
0:00 Introduction
2:35 A well structured codebase is easy to visualise
4:43 the component exists conceptually
4:57 Abstractions should reflect the code
7:17 Our architecture diagrams don't match the code.
7:56 The code structure should reflect the architectural intent
8:33 Organise code based upon what the code does from a technical perspective
8:41 Package by layer is a "horizontal" slicing
9:11 Relaxed vs strict layering
11:53 Changes to a layered architecture usually result in changes across all layers
12:42 Organise code based upon what the code does from a functional perspective
12:56 Package by feature is a "vertical" slicing
13:31 Cited benefits include higher cohesion, lower coupling, and related code is easier to find
15:04 The "inside" is technology agnostic, and is often described in terms of a ubiquitous language
20:09 Architectural principles introduce consistency via constraints and guidelines
20:27 web controllers should never access repositories directly
22:51 Tooling? Static analysis tools, architecture violation checking, etc
23:18 types in package **/web should not access types in **/data
23:55 Using tools to assert good code structure seems like a hack
24:38 But Java's access modifiers are flawed...
25:50 Component? a grouping of related functionality behind a nice clean interface, which resides inside an execution environment like an application
27:08 Package by component is about applying component-based or service-oriented design thinking to a monolithic codebase
27:28 Modularity as a principle
27:54 Separating interface from implementation
28:12 Impermeable boundaries
29:21 The devil is in the implementation details
30:15 Organisation vs encapsulation
34:49 Use encapsulation to minimise the number of potential dependencies
35:38 If you're building a monolithic application with a single codebase, try to use the compiler to enforce boundaries
36:01 Or other decoupling modes such as a module framework that differentiates public from published types
39:08 Agility is a quality attribute
39:45 A good architecture enables agility
45:58 Whatever architectural approach you choose, don't forget about the implementation details
46:13 Beware of the model-code gap
Download slides and read the full abstract here:
gotober.com/2018/sessions/515
RECOMMENDED BOOK
Simon Brown • Software Architecture for Developers Vol. 2 • leanpub.com/visualising-softw...
/ gotober
/ gotoconference
/ goto-
gotocon.com
#EventDrivenArchitecture #Monoliths #ModularMonoliths #SoftwareArchitecture
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf... - Наука та технологія
This talk is as relevant and insightful today as it was 5+ years ago. It should have way, way more views and likes and discussion. Like most, I've seen and suffered under both extremes... horrifying, ancient big balls of monolithic mud where it was terrifying to change anything vs. knee-jerk microservice zealotry. I'm trying to find and promote a bit of sanity by adopting modular monoliths. The devil's definitely in the details. I'm still trying to get my head around the practical considerations of data encapsulation/boundaries when so much data has been traditionally shared (JOINs, JOINs everywhere). But this is a great overview and a thought-provoking reminder that good design is good design. Thank you, Simon!
Pure Gold. Finally, we are rescuing the foundational principles of how to make good software from to the roots of our industry and appliying those principles on modern technologies. Fantastic.
"Choose microservices for the benefits, not because your monolithic codebase is a mess"
Definitely the best talk I ever saw on software architecture!
Thank you for a very insightful and intelligent talk.
Setting strong foundations and setting it right at the very start, enjoyed it thoroughly...
Great and interesting talk! I like the idea that we should first start up with modular monolith and than switch to microservices eventually.
Thanks!
Very nice, explained exceptionally well
Great talk! A lot of things boil down to common sense.
Great talk Simon Thanks.
I just re-read the missing chapter this weekend. Didn't put it together that it was /this/ Simon Brown. Good stuff!
Perfect!
awesome!! thanks
Simon Brown is such a treasure trove of accessible insight on complex architectures (and a fox to look at too), love his talks.
That was really good
I would like to throw modules into the 'Java doesn't have a component keyword" debate
I use "Package by Feature" but each package has own additional package with Contracts. Thanks to that I can make everything private also with controller into that package and external package can use Contracts (which are public and this is only referenced by other features) to use functions from that package. Nice and clean.
I don't understand what you are saying. but it sounds like a good thing.
@@marikselazemaj3428 Hahaha, relax.
Ok. Good. What should I do, if I don't use spring annotation configuration? How can I create impl classes with package modifier? I know only one way - spring annotation configuration. Architecture for spring?
I somehow missed the part where he talks about modular monoliths in any detail.
Some good information in places, but I'm still not sure what a modular monolith is after this talk.
Great talk, Simon is certainly one of the best when it comes to delivering actionable, no-nonsense wisdom.
Coming from Rails, I'd certainly find it beneficial to be able to "slice the monolith up vertically", hiding some group of models/services from the rest while being able to define public interfaces that are OK to access from anywhere. Engines?
Thanks…How would an order component communicate with another component say user management to authenticate users for example if you decide to modularise them?
Amazing talk! I am still trying to answer one question in all the 4 approaches, how to communicate with other components? Like Orders component needs information from the Customer component, how and where the two components communicate to get information, Order getting information about the Customer in all the 4 approaches
ua-cam.com/video/MkdutzVB3pY/v-deo.html&ab_channel=DevMentors
This video has a lot of implementation-related details about modular monoliths.
Me: "The root cause of our problems is poor encapsulation."
My boss: "That sounds like a code-level thing. Get your head out the sand."
Engineer: "We've added a thing for that."
I would make the controller package protected. Spring can instatiate it. Nobody from code needs to invoke it.
Great talk. My OCD is being triggered by the slide at 30:30
"People use microservices to enforce code boundaries", do they really? Yes it is the ultimate form of code boundaries but that's not the reason for doing it. The reason is the possibility to deploy and scale parts of the application independently.
Whether your component is a microservice or not is a detail of implementation, in my opinion. Scaling a component should not be a task much harder than separating an interface from a class. As such, you do not need the microservice architecture to scale your application in the first place, but microservices naturally arise, when the intent to scale only a part of components in your monolith begins.
"Clean architecture" /Onion can have also a huge overhead in simple systems.
E.g. Forcing always!(!) every call to go from webcontroller DTOs, to domains (domain object) Is what I call a mapping-hell.
Hey, isn't Simon Brown the C4 software architecture guy? Documentation = The Architecture.
Too bad I've started learning about distributed monoliths only after I've wasted 3 years working on one. Well, I didn't have the experience, I went to work on a system I did not understand from the domain perspective, it turned out later on that it is actually a distributed monolith because of various dependencies I did not know about. So pls, understand the domain before jumping on coding, do what Simon is talking about, you will save yourself a lot of pain, lost time and lost money for the company you work for...
Thanks man, those were the last words convincing me that microservices are not the way to follow at least not now for the application I'm building, and the n of people working on it (just me).
I don't know why, but I realised that microservices maybe are following what human interaction is like in these days: people tend to stay more in their little worlds, instead of trying to be a part of a whole thing. Communication most of the time is not very good, and costs a lot.
LOL 😂
.... Anyway, my concern is an asynchronous service that runs an heavy algorithm, and I'm thinking about isolating, it in order to run N instances in parallel.
I have lots of perplexities regarding the data produced by this service, due to the fact that one instance cannot be unaware of what the other is doing, in order to produce a good (and feasible) result.
I mean... What the hell! Do we really need to learn containerization?
Why do we need to throw away years of good stuff (relational databases, just to say one)?
Wouldn't be simpler to have a smarter JVM, capable of a container like features only where needed?
Excuse my ignorance about the topic, I really appreciate how fast you can setup an environment with docker, but.... I think that better solutions still have to come in the next years, and maybe they will be a good balance between the past techniques and the present ones... Balance!! It's always the best solution!
I don't think everything has to be a first class citizen. From my experience, it will get abused. Just like "Service" - XService, YService, BlablaService, UselessService. All the services. Its tiring. 13:30 - I would say it is better because the concept of feature is better contained than the concept of layer. Every time I went from layers to vertical slicing my solution, I found that I understand and navigate the code much easier afterwards.
CV-driven design! lol
"Tweet component does not actually exist when you zoom in."
Do you also think a building you just entered into does not exist as well?
Well, I'd argue "zooming in" is not the same as "entering", but much closer to "walking up to" (a building). Having an actual Tweet module VS having a conceptual Tweet module that consists of two files/classes which sit among other files for other features, is different IMO.
OSGi to the rescue.
Love Simon's work and content, surely the answer is to stop using Java ;) (joking, but kinda not)
"... we just type 'public' by default and we don't know why. It's muscle memory..." That's what kills the modular design principle...
The problem I have been facing in architecture
Hah "CV Driven Design"
I am definitely using this one!
*TL;DW*
Don't do microservices to make your code base more modular do it because you really need to be able to deploy and scale parts of your application separately. Instead make your codebase more modular by using a better package structure and careful use of *public* classes.
(Interesting talk but could have been done in 15 minutes)
Thanks, my friend.
Concept driven development? To which problem the solution is? Business? Code structure should rather reflect organizational structure. At least, this (org.structure) seems to be much more stable than rapidly changing functions, technologies and context. The architecture evolves dramatically while organizational structure doesn't! The more the drivers for codebase are stable, the less effort/risk/spending/learning curve is.
When you say org structure, what do you mean? Frontend, backend, db, etc? Just need clarification.
This would be Conway's Law in action.
I thought this was obvious to most people? 😅🤔
"All these programmers are cargo cult programmers that follow what somebody is saying." - Presenter "Here, I have my own cargo." - Also the Presenter
😀
Well, at least the presenter in this case explains the reasons
Super boring, outdated, old.
I'm kind of a Newbie and interested in your opinion.
Could you add some more details why the talk is for you "super boring, outdated, old."?
Are you probably not the "target audience" (e.g. beginner/intermediate but not expert)?
What talk recordings, books, blog posts, etc would you recommend to other "more expert" people in this field to get some good "learning stuff"?
Thank you for your help from an another human being trying to "understand better"! Peti
@@PetiKoch I am guessing here, but brobably anything which isn't microservice lambda serverless reactive stream is super boring outdated old stuff.
Tell us more about your avatar... It looks brand new!
Do you mind expanding on how it is outdated and old?
@@PetiKoch Ignore him. Starting at 34:36, from here on should be a blueprint for startups. Start with a monolith, work on developing bounded business contexts "in-process" by increasing cohesion and decreasing coupling (modules + interfaces), before moving your cohesive modules "out-of-process" (microservices)