Dark energy force: simple components
a dark energy, dark matter force
Components should be easy to understand and maintain. A component should have an easily understood structure. It should be modular and have a small number of dependencies (libraries and other services). A component should also have easily understood runtime behavior. In particular, the requests that it handles should be similar in nature, e.g. have similar resource requirements.
There are two ways to achieve this goal:
- Design components to be as simple as possible
- Design a complex component as modular monolith
Let’s look at each approach.
Design components to be as simple as possible
One way to achieve simplicity is to design components that:
- are as simple as possible
- have as few dependencies as possible
- handle requests that have similar runtime behavior.
In other words, we should minimize the number of subdomains that are group together into a component. You could consider this approach to be an application of the Single Responsibility Principle although the term ‘responsibility’ is somewhat imprecise.
Design a complex component as a modular monolith
While designing components to be simple is a good goal, it’s not always possible. Because of conflicting dark matter forces, you might have to design a complex component, such as a monolith. One approach for making a complex component easier to understand and maintain is to design it as a Modular monolith. Since the code base is organized around subdomains, it’s a lot easier to understand and maintain than one that is organized around technical layers.
One limitation, however, of a modular monolith is that it might still have a large number of dependencies. It might also implement a lot of diverse functionality. Consequently, its runtime behavior might be difficult to understand and troubleshoot. It might, for example, handle a mixture of short-running requests and long-running batch jobs.
Premium content and office hours is now available for paid subscribers at 
