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 not silver bullet.
Instead, I recommend using criteria based on dark matter and dark energy to evaluate a potential solution or to compare multiple candidate solutions. 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.
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.
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
System operations also model actions that are triggered by the passing of time.
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
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
Kitchen Management, and
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
This is where the metaphors of dark energy and dark matter can help.
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.
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.
Let’s first take a look at dark energy.
There are several 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.
There are the following 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.
See these presentations:
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.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
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 JUNVCEJE to sign up for $195 (valid until February 1st, 2023). There are deeper discounts for buying multiple seats.
Chris offers numerous resources for learning the microservice architecture.
Chris teaches comprehensive workshops, training classes and bootcamps for executives, architects and developers to help 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.
Delivered in-person and remotely.
Want to see an example? Check out Chris Richardson's example applications. See code
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.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · dark energy and dark matter · deployment · development · devops · docker · implementing commands · implementing queries · inter-service communication · 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 · team topologies · transaction management · transactional messaging