CodeParkA modular monolith is one deployable application split into modules by business domain, such as orders, billing and catalog. Each module has clear boundaries. You keep the simple deployment and local transactions of a monolith. You also get much of the structure of microservices.
The rules that make it work:
- Each module exposes a public interface and keeps its internals private. Other modules never reach into its classes or repositories.
- Each module owns its data, ideally its own schema or tables. No other module queries them directly.
- Dependencies between modules are explicit and checked by tools, for example lint rules or architecture tests.
- Modules can talk through in-process events where loose coupling helps.
The pay-off comes later. Suppose one module really needs to scale or deploy on its own. You can extract it into a separate service with little rework, because its boundary already exists.
- It is one deployable, with modules split by business domain.
- Each module has a public interface and keeps its internals private.
- Each module owns its data, and others never query it directly.
- Tools such as lint rules or architecture tests enforce the boundaries.
- A module is easy to extract into a service later.