How big is the team modifying the code ? Wondering how, let's say 10 modules live together and evolve over time. Will some get orphaned ? Will deployment be a bottleneck with multiple teams owning this monolith?
Somebody seriously needs to make a talk why _not_ just turn everything into completely independent modules. Or at least where to put the boundaries. Hint: There is a cost to it, just as the cost of updating a monolithic codebase.
Exactly. A module is not an entity, instead the same rules applied to find the boundaries of a Microservice can be applied to design a module. A module can have just a single entity if it doesn't depend on anything else in the system.
> Meaning changes when going from module to module, here it's not ItemPrice, its CatalogItemPrice. There it's not ItemPrice, it's CartItemPrice. Reminds me of bounded contexts from DDD (the meaning of a laguage term changes from context to context). Why no reference to that, Jimmy?
(From my experience) people start rolling their eyes every time they hear about complex concepts such as ddd, solid, xp, structured design, etc. it's easier to make them understand the rationale behind the concepts and only then say "...and that's what DDD/SOLID is about"
How many fundamentally different commercial business processes that can be embodied in software are there really, given that details can be parameterized or templated? Am I wrong in thinking the same wheels are being reinvented over and over again?
> Am I wrong in thinking the same wheels are being reinvented over and over again? No, your hunch is absolutely correct. That's why GitHub exists - programmers got tired of writing the same stuff over and over.
They definitely are being reinvented over again, but that’s because people have slightly different business structures even in the same industry. If every business were structured exactly the same, there would be no differentiation in the market. For example, everything involved in home maintenance would be easier and cheaper if every house were identically built. However, for a variety of reasons, we would never do that.
While the ideas are okay i still don't see how this enables us to deploy easily without stepping on other teams' toes. Thats an incredibly huge benefit of microservices. Also if we have follow these rules to build maintainable monoliths why can't we follow the proper microservices rules?
Did you watch the video? His whole point is that you won’t know where to draw the boundaries around your micro services until you start building as a monolith. You figure out which features should be grouped into modules (microservices) by investigating how frequently they reference each other; not the other way around.
Most of these points seem to be applicable to microservices in a monorepo aswell. Yes deployment topics are difficult but there is a high chance that you are going to end up with threading/performance issues on huge services which are no bit easier to debug imho. Once you run into performance / memory issues you probably wish you could narrow the search down to one kubernetes pod of service x instead of "the application". Not saying i dont like modular monoliths, they are the way to go for new projects id say. But nothing more.
There are many ways of finding performance bottleneck to for instance an endpoint (just logs will give you that) or even line level with profilers. Not sure how microservices makes that easier imho.
@@Rick104547Sure, never said its impossible :) multiple deployment units should have less complexity and therefore less potential breaking points. Splitting off functionality that is mature to some degree seems to be the way to go in my opinion. Still, having worked with microservices for quite a while i wouldnt recommend the "micro" part, especially not as a starting architecture for a new project.
With all due respect, there are so many self-contradictory statements here that one could literally say they are modularizing their application when doing the exact opposite. Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice? The obvious answer is nowhere. If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice? Why even bother discussing vertical slices and modularity if you are going to immediately give up and break encapsulation?
> Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice? Usually it happens in Apllication Services or Transaction Scripts > If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice? To get different services work together you should always bring some coupling. If your boundaries are correct then the coupling is called "loose"
Ideals don't usually end up in the implementation though. Someone at some point will make a mistake to break the encapsulation and it's going to end up in the code base.
I have been writing all my software like this for the past 6 years, never needed any other way. Fantastic talk.
How big is the team modifying the code ? Wondering how, let's say 10 modules live together and evolve over time. Will some get orphaned ? Will deployment be a bottleneck with multiple teams owning this monolith?
This is a fantastic talk and it has been featured in the last issue of Tech Talks Weekly newsletter 🎉
Congrats!
Somebody seriously needs to make a talk why _not_ just turn everything into completely independent modules. Or at least where to put the boundaries.
Hint: There is a cost to it, just as the cost of updating a monolithic codebase.
Oh. Would love that!
Exactly.
A module is not an entity, instead the same rules applied to find the boundaries of a Microservice can be applied to design a module.
A module can have just a single entity if it doesn't depend on anything else in the system.
Will be an interesting watch!
> Meaning changes when going from module to module, here it's not ItemPrice, its CatalogItemPrice. There it's not ItemPrice, it's CartItemPrice.
Reminds me of bounded contexts from DDD (the meaning of a laguage term changes from context to context). Why no reference to that, Jimmy?
(From my experience) people start rolling their eyes every time they hear about complex concepts such as ddd, solid, xp, structured design, etc. it's easier to make them understand the rationale behind the concepts and only then say "...and that's what DDD/SOLID is about"
@@FenelZ "complex" lmao the only complex thing is my inferiority complex
been there 3years counting. not seeing the ends yet. decoupling is hard
How many fundamentally different commercial business processes that can be embodied in software are there really, given that details can be parameterized or templated? Am I wrong in thinking the same wheels are being reinvented over and over again?
> Am I wrong in thinking the same wheels are being reinvented over and over again?
No, your hunch is absolutely correct. That's why GitHub exists - programmers got tired of writing the same stuff over and over.
They definitely are being reinvented over again, but that’s because people have slightly different business structures even in the same industry. If every business were structured exactly the same, there would be no differentiation in the market.
For example, everything involved in home maintenance would be easier and cheaper if every house were identically built. However, for a variety of reasons, we would never do that.
3:56 bis 6:30 the Problem with boundaries and Microservices, führt zu wir wollen Modularisierung ohne big ball of mudd
While the ideas are okay i still don't see how this enables us to deploy easily without stepping on other teams' toes.
Thats an incredibly huge benefit of microservices. Also if we have follow these rules to build maintainable monoliths why can't we follow the proper microservices rules?
Did you watch the video? His whole point is that you won’t know where to draw the boundaries around your micro services until you start building as a monolith.
You figure out which features should be grouped into modules (microservices) by investigating how frequently they reference each other; not the other way around.
When was this originally aired
It seems that the event itself where this was recorded was in May this year.
25:54 hidden ads exposed
Most of these points seem to be applicable to microservices in a monorepo aswell. Yes deployment topics are difficult but there is a high chance that you are going to end up with threading/performance issues on huge services which are no bit easier to debug imho. Once you run into performance / memory issues you probably wish you could narrow the search down to one kubernetes pod of service x instead of "the application". Not saying i dont like modular monoliths, they are the way to go for new projects id say. But nothing more.
There are many ways of finding performance bottleneck to for instance an endpoint (just logs will give you that) or even line level with profilers.
Not sure how microservices makes that easier imho.
@@Rick104547Sure, never said its impossible :) multiple deployment units should have less complexity and therefore less potential breaking points. Splitting off functionality that is mature to some degree seems to be the way to go in my opinion. Still, having worked with microservices for quite a while i wouldnt recommend the "micro" part, especially not as a starting architecture for a new project.
With all due respect, there are so many self-contradictory statements here that one could literally say they are modularizing their application when doing the exact opposite.
Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice?
The obvious answer is nowhere. If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice?
Why even bother discussing vertical slices and modularity if you are going to immediately give up and break encapsulation?
> Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice?
Usually it happens in Apllication Services or Transaction Scripts
> If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice?
To get different services work together you should always bring some coupling. If your boundaries are correct then the coupling is called "loose"
Ideals don't usually end up in the implementation though. Someone at some point will make a mistake to break the encapsulation and it's going to end up in the code base.
First
JAVA OSGI ?