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 and work on the software because we don’t have to jump from one place to another to get things done. So, if one module needs an update or has a problem, we can fix it without touching the others. This segregation is also perfect for testing since we can test each module in isolation to ensure it works well. For example, one module might handle a shopping cart while another takes care of the shipping, but we piece all modules together in a final aggregated application.