It is a misconception that monoliths are only suitable for small projects or small teams. A well-built monolith can go a long way, which is what a modular structure and a good analysis bring. Modular Monoliths can be very powerful and work well for different sizes of projects. It is essential to consider the pros and cons of each approach when selecting the application pattern for a project. Maybe a cloud-native, serverless, microservices application is what your next project needs, but perhaps a well-designed Modular Monolith would achieve the same performance at a tremendously lower cost.To help you make those…
-
-
The modules of this application follow the previously discussed URI space: /{module name}/{module space}. Each module has a Constants file at its root that looks like this: namespace REPR.Baskets;public sealed class Constants{ public const string ModuleName = nameof(Baskets);} We use the ModuleName constant in the {module name}ModuleExtensions files to set the URI prefix and tag the endpoints like this: namespace REPR.Baskets;public static class BasketModuleExtensions{ public static IEndpointRouteBuilder MapBasketModule(this IEndpointRouteBuilder endpoints) { _ = endpoints .MapGroup(Constants.ModuleName.ToLower()) .WithTags(Constants.ModuleName) .AddFluentValidationFilter() // Map endpoints .MapFetchItems() .MapAddItem() .MapUpdateQuantity() .MapRemoveItem() ; return endpoints; }} With this in place, both modules self-register themselves in the correct URI…
-
Planning is a crucial part of any software. Without a plan, you increase your chances of building the wrong thing. A plan does not guarantee success, but it improves your chances. Overplanning is the other side of this coin. It can lead to analysis paralysis, which means you may never even deliver your project or that it will take you so long to deliver it that it will be the wrong product because the needs changed along the way and you did not adapt.Here’s a high-level way to accomplish planning a Modular Monolith. You don’t have to execute all the…
-
The first thing to know about Modular Monoliths is that they are composed of different parts called modules. Each module is like a mini-app that performs a specific job. This job is related to a particular business capability. A business capability comes from the business domain and aims at a cohesive group of scenarios. Such a group is called a bounded context in DDD. Think of each module as a microservice or a well-defined chunk of the domain.That separation means everything we need to complete a specific task is in one module, which makes it easier for us to understand…