@@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.
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 😊
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
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.
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.
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.
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.
Why do so many coders on TH-cam use their normal screen resolution, thinking that everyone is watching on a 4k monitor.. it's not readable on a laptop. There is a reason why most IDEs have a 'presentation mode'.
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Excellent video, Milan! This is more clear for me!
The next video should help even more
This is awesome and useful content thank you
Glad you think so!
Awesome content, thanks for all the knowledge!
Most welcome!
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.
Excellent video Milan! I'm looking forward to future episodes of this series
More coming :)
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.
next video should be "creating beautiful micro services app with Aspire NET" 😊
Challenge accepted
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
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
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.
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
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.
Have you ever used the Managed Extensibility Framework (MEF) with a modular monolith before?
No, I haven't
I'm wondering why is it still called a monolith? Because of inproc nature?
It's one deployment unit / single application
Activities suddenly appeared
Copy-paste
Why do so many coders on TH-cam use their normal screen resolution, thinking that everyone is watching on a 4k monitor.. it's not readable on a laptop. There is a reason why most IDEs have a 'presentation mode'.
This is the first time I hear of presentation mode, to be fair
Hi Milan! What keyboard are you using?
I believe Logitech g413 carbon
Great video Milan. Keen to see the rest of this series!
Thanks, it's coming together coming slowly