About dark energy and dark matter: forces that shape an architecture

dark energy and dark matter  

---

---

When designing and evolving an architecture there are numerous decisions that you must make. Three key decisions are:

• Whether to use the monolithic architecture or the microservice architecture?
• When implementing a new feature should you define a new service or enhance existing services?
• When designing an operation that spans multiple services, which collaboration patterns should you use and how?

The answer to all of these questions is that it depends. Specifically, it depends on the dark energy and dark matter forces.

What are the dark matter and dark energy forces?

Dark matter and dark energy are mysterious concepts invented by astrophysicists in order to explain certain astronomical observations. Dark energy is an anti-gravity that is forcing matter apart and accelerating the expansion of the universe. Dark matter is an invisible matter that has a gravitational effect on stars and galaxies. They are excellent metaphors for the repulsive and attractive forces (a.k.a. concerns) that must be resolved when designing an architecture.

They are the forces that encourage and resist decomposition of a system into smaller components, a.k.a. service.

Let’s first look at the dark energy forces and after that the dark matter forces.

Dark energy forces - encouraging decomposition into services

There are five dark energy forces that encourage decomposition and promote the use of the microservice architecture:

• Simple components - simple components consisting of few subdomains are easier to understand and maintain than complex components
• Team autonomy - a team needs to be able to develop, test and deploy their software independently of other teams
• Fast deployment pipeline - fast feedback and high deployment frequency are essential and are enabled by a fast deployment pipeline, which in turn requires components that are fast to build and test.
• Support multiple technology stacks - subdomains are sometimes implemented using a variety of technologies; and developers need to evolve the application’s technology stack, e.g. use current versions of languages and frameworks
• Segregate by characteristics - e.g. resource requirements to improve scalability, their availability requirements to improve availability, their security requirements to improve security, etc.

Dark matter forces - resisting decomposition into services

There are five dark matter attractive forces that resist decomposition and promote the use of the monolithic architecture:

• Simple interactions - an operation that’s local to a component or consists of a few simple interactions between components is easier to understand and troubleshoot than a distributed operation, especially one consisting of complex interactions
• Efficient interactions - a distributed operation that involves lots of network round trips and large data transfers can be too inefficient
• Prefer ACID over BASE - it’s easier to implement an operation as an ACID transaction rather than, for example, eventually consistent sagas
• Minimize runtime coupling - to maximize the availability and reduce the latency of an operation
• Minimize design time coupling - reduce the likelihood of changing services in lockstep, which reduces productivity