I just published a new side project of mine, for creating modular monoliths.
It’s very early stage. Not more than an outline. I’m curious what you think about it, please leave me a note in the comments.
Each module is contained in its own Gradle project. Apart from main and connector, the modules have no dependencies.
This modular style of development potentially has the following benefits:
- The modules mark team boundaries. Each team can work on its own data and behavior, hardly affected by the work of other teams. That can reduce the time to market of development teams.
- Isolating the modules reduces cognitive load. A developer no longer needs to understand the whole application, but only the module she works on.
- Reducing the dependencies avoids the dreaded big ball of mud, and makes the application in general more maintainable. In particular, it avoids cyclic dependencies between parts of the application.
This modular style has the following downsides:
- It leads to eventual consistency. Since the modules communicate asynchronously, there is no guarantee for immediate consistency of data between modules.
- More effort for reliable messaging. In a real world application, it must be made sure that no events get lost. This complicates the infrastructure logic.
Top comments (0)