When designing an application’s architecture there are numerous decisions that you must make. For example:
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 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.
An application’s system operations and subdomains are an implementable model of its functionality.
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.
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.
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.
Given the above definitions of subdomains and components, the problem of defining (the implementation view of) an architecture becomes
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.
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.
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:
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.
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:
Sometimes, you can reduce the strength of those forces by redesigning the operation. Alternatively, you might need to repartition the subdomains.
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.
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.
See these presentations:
I provide consulting and training to help you use the microservice architecture effectively.
Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.
Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.
Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.
Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.
Learn moreChris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
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 MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
Use the Eventuate.io 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.
Engage Chris to conduct an architectural assessment.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · development · devops · docker · eventuate platform · glossary · hexagonal architecture · implementing commands · implementing queries · inter-service communication · kubernetes · loose coupling · microservice architecture · microservice chassis · microservices adoption · microservicesio updates · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · tacos · team topologies · transaction management · transactional messaging