Designing an architecture using dark matter and dark energy

application architecture   architecting   dark energy and dark matter   assemblage  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.

Updated March 2023

When designing an application’s architecture there are numerous decisions that you must make. For example:

  1. Should the application have a monolithic or a microservice architecture?
  2. If you use the microservice architecture, what are the best service boundaries?
  3. How to design an operation that spans multiple services?

When working with clients, I’m often asked “What’s the best way to do X?”. Almost always, my answer is “It depends!”. Specifically, the best solution depends on the specific context within which you are trying to solve the problem. Sadly, there’s no silver bullet. Instead, I recommend using criteria based on dark matter and dark energy to drive the design of the architecture.

Dark energy and dark matter drive architecture design

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. As I described in my iSAQB and Mucon presentations, I use them as metaphors for the repulsive and attractive forces that must be resolved when designing an architecture.

But Before talking about how to apply the metaphors of dark matter and dark energy, I want to first talk about two inter-related concepts: system operations and subdomains.

About system operations and subdomains

An application’s system operations and subdomains are an implementable model of its functionality.

System operations

System operations are a distillation of an application’s functional requirements (e.g. stories). Each one is an abstract representation of a request that an application must handle. For example, the FTGO application implements system operations, such as createOrder(), cancelOrder(), and findOrderHistory(). System operations also model actions that are triggered by the passing of time.

The first step of the Assemblage architecture definition process distills the application’s functional requirements into system operations. These system operations play a central role is the rest of the process.

System subdomains

An application’s functionality as described by the systems operations is implemented by a collection of subdomains. A subdomain is an implementable, (usually) object-oriented model of a business capability. It’s owned by a small team, which is responsible for its development. For example, the FTGO application has numerous subdomains including Order Management, Delivery Management, Restaurant Management, Kitchen Management, etc. And, since it’s a Java application, each subdomain is a collection of Java packages that contain classes.

Each system operation spans one or more subdomains.
For example, the createOrder() system operation spans numerous domains including Order Management, Restaurant Management, Kitchen Management, and Accounting.

The second step of the Assemblage architecture definition process designs the application’s subdomains.

An application’s subdomains comprise the logical (a.k.a. development) view of its architecture. We also need to consider the implementation view, which defines how those subdomains are packaged as components, which are executable/deployable units.

What’s the architecture’s implementation view

The implementation view defines the application’s modules and components. A module is a compiled and packaged subdomain. A component is an executable or deployable and consists of one or more modules. In a Java application, a module is a JAR file and so each subdomain would be packaged as a one or more JAR files. A Java component is a WAR file or an executable fat JAR file. that contains a collection of JAR files.

If an application consists of a single component then it has a monolithic architecture. Alternatively, if it consists of two or more components then it has a microservice architecture.

Defining an application’s implementation view

Given the above definitions of subdomains and components, the problem of defining (the implementation view of) an architecture becomes

  1. How to partition an application’s subdomains into one or more components, a.k.a. services? For example, given three subdomains: A, B, C, there are numerous ways to partition them into three services: ABC; AB + C; A + B + C; AB + C; AC + B; A + BC.
  2. Given a partitioning, how to design those system operations that span services?

It’s imporatnt to keep in mind that these two problems are inter-related. For example, a given partitioning might prevent you from implementing a system operation efficiently. As a result, you might need to redesign the partitioning.

Let’s now look at how the metaphors of dark energy and dark matter can help you solve these problems.

About dark energy and dark matter

The following diagram shows the dark energy and dark matter forces. There are ten forces in total. Five repulsive dark energy forces and five attractive dark matter forces.

Let’s first take a look at dark energy.

Using dark energy

Astrophysicists invented the concept of dark energy to explain why the expansion of the universe, which was previously slowing down, started to accelerate 7 billion years ago. The theory is that as the universe expanded gravity weakened and eventually dark energy, which is an anti-gravity repulsive force, became dominant and accelerated the expansion. Dark energy a useful metaphor to explain the repulsive forces that encourage the partitioning of subdomains into more than one service.

There are five dark energy forces that act on subdomains and encourage the partitioning of subdomains into multiple services:

  • Simple components - simple components 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
  • Fast deployment pipeline - fast feedback and high deployment frequency are essential and are enabled by a fast deployment pipeline
  • 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 - subdomains can be segregated by their characteristics such as their resource requirements, their availability requirements, their security requirements, etc.

These repulsive forces act on subdomains and encourage them to be packaged as separate services. However, they aren’t the only forces you must consider. You must also consider attractive forces.

Using dark matter

When astrophysicists looked at orbits of stars in distant galaxies, they discovered that they moved faster than expected based on the amount of visible matter. To explain this discrepancy, they invented the concept of dark matter, which is an invisible form of matter that exerts a gravitational attraction. It’s a useful metaphor for the attractive forces in a microservice architecture that resist decomposition into services. These attractive forces that act on subdomains are generated by system operations that span those subdomains.

There are five dark matter attractive forces that resist decomposition:

The strength of the attractive forces that an particular system operation generates depends on two factors:

  1. How the subdomains that it references are partitioned into services
  2. The patterns that used to implement the operation

Sometimes, you can reduce the strength of those forces by redesigning the operation. Alternatively, you might need to repartition the subdomains.

Designing an architecture = balancing dark matter and dark energy forces

One reason the monolithic architecture is so appealing is that it satisfies all of attractive forces. Sadly, however, it neglects all of the repulsive forces especially when the application is large. At the other end of the spectrum, a fine-grained microservice architecture satisfies all of the repulsive forces yet might neglect the attractive forces. It might be a fragile distributed monolith that combines the worst of both architectural styles due to excessive design-time and runtime coupling.

The job of architect is to design an architecture that minimizes the repulsive forces within components AND minimizes the attractive forces between components. Future blog posts will do a deeper dive into dark energy and dark matter forces.

To learn more about designing a microservice architecture

Take a look at Introducing Assemblage - a microservice architecture definition process. Assemblage uses the concepts of dark energy and dark matter to design a microservice architecture.

To learn more about dark energy, dark matter and microservices

See these presentations:

Need help with microservices?

I provide consulting and training to help you use the microservice architecture effectively.

application architecture   architecting   dark energy and dark matter   assemblage  

Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon MJXJDTBJ to sign up for $95 (valid until May 22nd, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,

The Eventuate platform

Use the platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

Join the microservices google group