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.
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.
1. One global context 2. Multiple shared services 3. Private components 4. Component interaction only through shared services injected in the components. 5. Global context manager manages shared services. Spring got it right.
"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.
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
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...
"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.
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?
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.
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.
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."
Thanks…How would an order component communicate with another component say user management to authenticate users for example if you decide to modularise them?
*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 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!
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.
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.
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 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)
![Shareปลาวาฬ ส่งท้าย SS1 พาเปียโน ขึ้น Ferrari ก่อนไปขาย แลก Nissan l [Nickynachat]](http://i.ytimg.com/vi/KAknGkTNIvg/mqdefault.jpg)
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.
Great and interesting talk! I like the idea that we should first start up with modular monolith and than switch to microservices eventually.
Thanks!
Thank you for a very insightful and intelligent talk.
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.
Definitely the best talk I ever saw on software architecture!
Setting strong foundations and setting it right at the very start, enjoyed it thoroughly...
"Choose microservices for the benefits, not because your monolithic codebase is a mess"
Great talk! A lot of things boil down to common sense.
1. One global context
2. Multiple shared services
3. Private components
4. Component interaction only through shared services injected in the components.
5. Global context manager manages shared services.
Spring got it right.
"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.
I would like to throw modules into the 'Java doesn't have a component keyword" debate
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
th-cam.com/video/MkdutzVB3pY/w-d-xo.html&ab_channel=DevMentors
This video has a lot of implementation-related details about modular monoliths.
Import an instance of the public api of Customer into Order. It's not said that only http controller can use it.
Very nice, explained exceptionally well
I just re-read the missing chapter this weekend. Didn't put it together that it was /this/ Simon Brown. Good stuff!
Great talk Simon Thanks.
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...
"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.
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?
Simon Brown is such a treasure trove of accessible insight on complex architectures (and a fox to look at too), love his talks.
Perfect!
That was really good
awesome!! thanks
I would make the controller package protected. Spring can instatiate it. Nobody from code needs to invoke it.
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.
Hey, isn't Simon Brown the C4 software architecture guy? Documentation = The Architecture.
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.
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."
Great talk. My OCD is being triggered by the slide at 30:30
Thanks…How would an order component communicate with another component say user management to authenticate users for example if you decide to modularise them?
*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.
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!
"... we just type 'public' by default and we don't know why. It's muscle memory..." That's what kills the modular design principle...
CV-driven design! lol
Hah "CV Driven Design"
I am definitely using this one!
"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.
Love Simon's work and content, surely the answer is to stop using Java ;) (joking, but kinda not)
The problem I have been facing in architecture
OSGi to the rescue.
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)