the best part was the desktop mic catching all the pen clicking and ambient noise. But on a more serious note, Steve's stuff is consistently great. Very grounded and practical stuff. Keep it up!
This architecture does tend to work great for business applications in my experience. We’ve done so many half baked microservices attempts that end up with all of the negatives and few of the positives. This is the type of thing is a sweet spot for a lot of the types of things I have to build.
I think the hosts need to learn some video call etiquette and ensure they're muted when they don't need to talk. And also wait for the speaker to offer up opportunities to take questions, rather than asking and breaking up the flow of the presentation. Great talk from Steve though, very informative.
I have an email sending module and I need to have email templates for different entities that are in other modules. For instance, book back in stock email template, contact author email template, confirm email template (identity) etc. which staff can define via a cms. Where would these templates go, create a record for each template in the email sending contacts project?
what if there is an existing system running and the requirement is to rewamp the project and new and old project suppose to be running together for a perdior till then whole migration will be completed. WE are to go for modular monolith but using the same DBs. without making any change to it. Do we go with Mondular monolith with same db for all the module ?
I think that you can use the same db, but you should be very careful with sharing the data. In Steve's example all modules have their own database, and modules are not allowed to just 'peek' in other modules and use the other modules data. When all modules share the same database, I think it's very tempting to use your own data, and also peek into the other modules data via the database. For example when the order module gets data from the books table. You should decide which tables belong to which module, and maybe put them in separate schemas to prevent data leakage (and maybe use another db user which only has rights to it's own schema). But if you already are at that point, where tables are separated by their module, it's a short route to different databases.
How would you integrate a blazor frontend in this modular monolith architecture? Would you add an Web API layer (BFF) to orchestrate different modules into a viewmodel?
I would only add a BFF if it were a Blazor WebAssembly project, otherwise as long as you're just using the public contracts via mediator, there's no additional coupling.
I dispute that a Modular Monolith is easier to deploy than Microservices. The whole point of Microservices is that they're independently deployable. If your Users service, say, requires a change then you only need to deploy that one service - nothing else is affected. If you make a similar update to a Users module in a modular monolith, then you need to deploy the entire monolith. That's really a huge drawback, if you ask me. Related, what about separating the commits from each of the different modules - you absolutely will have to do that if you have different teams working on each module, all with different priorities, deadlines, sprint/iteration schedules, etc. This also makes the development/build/CI/deployment side of things incredibly complex. So much so that I don't see how there is any benefit to a Modular Monolith at all.
I think all those things you are bringing up are very valid points to push towards a microservices architecture, where you do have different teams working on each service with their own separate repos. The point that @ardalis was making is that everything in architecture is a trade-off. I feel that many of the comments and questions people were making during the video also were conflating this point, as they were asking things like, "but, how can I do this thing that I would do with microservices, but using mod monoliths??", and to which the answers were mostly, "well, you don't." :) Mod Monoliths are just another architectural style, and if you need it, it will fit very well with your needs as you'll be making very few tradeoffs. If you start having a lot of "friction", that means that perhaps some/all of your services would benefit from a different approach like microservices. The term "Module" and "Modular" can be very ambiguous to some, because they have past history (or might I even say, "baggage") with it. The comment about "COM" during the recording comes to mind. In a modular monolith style architecture like the one Steve shows, a module "solution folder", along with its respective module projects, is similar to just having a namespace and folders, but with a lot more rigor around coupling and avoiding spaghetti references - that is why he uses the .NET project system along with access modifiers. He even answers a question about how to ensure devs do the right thing, to which he says, "leverage code reviews, architecture unit tests, and educating your team mates to follow the proper patterns". Ok, now I'll get off my soapbox. Hope this doesn't come across as attacking but merely to add to your very valid points.
@@tafs7 I get it, I definitely see that there's a case for modular monoliths - and I think we've both covered the obvious reason for choosing one over the other (team size/responsibility). However he did specifically call out deployment as being "easier" for Modular Monoliths and I disagree strongly with that assessment. That's all my point was really. I understand that each has its place, and I actually think that in many small to medium sized orgs, and even in some enterprises, Modular Monoliths definitely can help make things better, but they're never going to be easier to deploy than a distributed microservices architecture, unless you're deploying the entire architecture at one time.
Good presentation, but I have to say the bombardment with popups on the bottom left is really distracting. It's not particularly relevant to the topic to know where the viewers are from. Background noise isn't good either.
There’s a fundamental flaw with the given examples, and that’s reflected in the questions asked too. I don’t think the application described is big enough to even break into separate isolated modules. A module is not the correct design here. The whole point of monoliths is to not prematurely decompose the app. The app should go through an architectural design phase where each piece of functionality is properly designed to ensure SOLID type principals first. If from that process there appears to be distinct modules, then and only then would you consider extracting modules.
So you invite one of the great .NET people and you start doing something else during the meeting. You can see the eyes and faces move all over the place.
All you've done is shifted the composition and aggregation of data naturally present in the backend to the worst possible place - the front-end UI. For your most basic screen in any ecommerce app, you'll be calling nearly every modules' APIs just to get one view. The fact this demo intentionally excludes that piece of the puzzle is revealing. This choice of architecture necessarily mandates another state store in the UI. Which brings a host of complications and makes your UI now a ball of mud. I get it's all tradeoffs. But excluding that vital layer from the presentation altogether doesn't present a balanced picture of what those trade offs actually are.
I think you've missed something. In a microservices setup you might have a "backend for frontend" or "gateway api" service that does this composition and aggregation you want. There's nothing stopping you from having the same "query service for frontend" module in this modular monolith.
@@steven11101010 I did when I suggested the solution to your problem already exists in the microservices world and can be easily adapted to the Modular Monolith world. Just to be explicit: The problem you raise is solved in the Microservice world by using Gateway APIs or a Backend for Frontend. Essentially, something responsible for doing the "composition and aggregation of data", as you put it, instead of the UI. In the Modular Monolith world you could assign this responsibility to a dedicated module. Same solution, different context.
@@steven11101010 I did when I suggested the solution that works in a Microservices context would also work in a Modular Monolith context. Specifically: In the MS context we sometimes use a "Backend for Frontend" or "Gateway API" to, as you put it, handle the "composition and aggregation of data." In the MM context a dedicated module can be created to handle this responsibility.
@@JeanQPublique Precisely. A BFF would be present for any SPA or mobile client application that might consume these APIs, and it's there that you would be sure to have efficient and well-factored endpoints in place dedicated to this or that client screen/page/control's needs.
