Modular Monolith - How To Create Your Modules
Вставка
- Опубліковано 30 чер 2024
- ☄️ Master the Modular Monolith Architecture: bit.ly/3SXlzSt
📌 Accelerate your Clean Architecture skills: bit.ly/3PupkOJ
🚀 Support me on Patreon to access the source code: / milanjovanovic
A modular monolith is an architectural pattern that structures the application into independent modules or components with well-defined boundaries. The modules are split based on logical boundaries, grouping together related functionalities. This approach significantly improves the cohesion of the system. In this video, I'll explain how to create modules in your application. We'll start with a monolith application using Clean Architecture and extract two distinct modules.
Check out my courses: bit.ly/3PupkOJ
What Is a Modular Monolith?
www.milanjovanovic.tech/blog/...
Monolith to Microservices: How a Modular Monolith Helps
www.milanjovanovic.tech/blog/...
Join my weekly .NET newsletter:
www.milanjovanovic.tech
Read my Blog here:
www.milanjovanovic.tech/blog
Chapters
0:00 How to define Modules
2:04 Defining Modules - guidelines
5:21 Extracting Modules in a monolith - Наука та технологія
💡You can learn more about Modular Monolith Architecture here: bit.ly/3SXlzSt
Excellent video Milan! I'm looking forward to future episodes of this series
More coming :)
Great video Milan. Keen to see the rest of this series!
Thanks, it's coming together coming slowly
Awesome content, thanks for all the knowledge!
Most welcome!
Excellent video, Milan! This is more clear for me!
The next video should help even more
next video should be "creating beautiful micro services app with Aspire NET" 😊
Challenge accepted
Nice and simple, one thing catches my eye, your Training Application module is dependent on User.Domain? Modules should share DTOs and interfaces using contracts. I guess this is a side effect of moving from monolit to modular monolit and in the next video you will deal with it. Nice work 😊
Exactly, I'll deal with it in a future video doing exactly what you suggested. Users module will expos a public API that the Training module can call.
This is fine for a theoretical experiment. But in practice the split will be decided by the topology of the teams which is a reflection of the business
Of course, this is a contrived sample
Hopefully ur modular monolith course will be great.
I'm excited. It'll end up being 12-15 hours of top-notch content. 😁
If it’s anything like the other course, I can’t wait!
@@jeremylarose5100 My opinion is this one is far better. I've learned a ton from some mistakes made on my first course.
@@MilanJovanovicTech If you put it like that, you're going to make it even more expensive than your other expensive course. I hope you don't set the bar high, because then there is a good chance that many people will look elsewhere!
@@daveanderson8348 It'll be pretty similar to the other one, with a lot more content.
But then again, how many other creators regularly update their existing courses or introduce new content? I don't know of many.
What are your thoughts about putting endpoints into the modules as well and making the API a pure presentation/implemenation layer? That way you're not bound to the API project. We've done something similar in a recent project we released where we had to deploy to the cloud as well as an executable running on a legacy machine on prem.
I've also done that, works great
Do Modular Monoliths have a way of communication other than using abstract Interfaces, thank you for this informative video
Yes. I'll talk about it in another video. But you can use messaging to communicate between modules.
How would you suggest fitting reporting into a modular monolith architecture?
Reports will likely pull data from multiple modules, so maybe all reports belong in their own module, but then that report module would communicate with several other modules.
You could also put the reports within the modules, but then they would have to potentially communicate to other modules.
What do you think?
The most elegant, and also most complex, approach would be publishing events and having the reporting module react to these events and update the required data.
We can also implement sync calls to other modules to gather the needed data, on demand.
@MilanJovanovicTech when you say sync calls, what do you mean?
I imagine maybe something about the data from the modules that the report needs get copied and transformed into a report specific data model (ie: "sync") the data, or are you referring to something else?
I'd be very interested in a video on this because I believe reporting is a requirement for a lot of projects that would justify a modular monolith architecture.
why don`t you post the code in the video to the github?) just a simple example :)
I'll work on a different project for GitHub, planning to release something over the summer to cover the popular architectures
Have you ever used the Managed Extensibility Framework (MEF) with a modular monolith before?
No, I haven't
shouldn't we move modules to separate solutions? even if keeping them in same solution, how about deploying them separately and reference them using nuget instead of project reference so later on it can be migrated easily to MS
I've worked on a project like that, and it requires A LOT of discipline from the team and generally a central architect. The reason being is that coordinating nuget updates becomes its own task. It makes the project more resilient to bad changes but comes with a lot of extra management and technical debt. It also requires a lot of coordination in regard to lower-level libraries among all projects.
For instance, you have two modules, Products and Orders, they may rely on some lower-level common libraries like Security, Common, Caching, etc. that your team also manages. If you update one of those, you now have to ensure that you propagate those to all of the high-level libraries or run the risk of collision in the main monolith project. It's fine for small teams and small projects, but as the team and project complexity grow, the technical debt to manage those types of references increases.
I think all larger projects should have a "keeper of the keys"/Architect as it were but not all teams get that luxury.
Where's the monolith part then?
I agree. Usually monoliths are not converted to MS at one go, instead follow strangler pattern to extract one module at time so both "modular monoliths" and new MS can co-exist
Wouldn't having the training module reference the user module not be a best practice and break the actual modularity?
What would you do in this case...extract IUserRepository and User domain into the shared kernel, leave it how you did it, or something else?
Wait for the next video (this week), but what we want to do is have Training reference the public API of the Users module. This can be as simple as exposing an interface, that will be implemented by the Users module.
Hi Milan! What keyboard are you using?
I believe Logitech g413 carbon
Activities suddenly appeared
Copy-paste