application architecture   architecting   dark energy and dark matter  

Designing an architecture using dark matter and dark energy

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 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.

About 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 createOrder(), cancelOrder(), and findOrderHistory(). 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 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.

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?
  2. Given that partitioning, how to design the system operations that span services?

This is where the metaphors of dark energy and dark matter can help.

About dark energy and dark matter

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.

Using dark energy

There are several 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 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 written using a variety of languages and developers need to evolve the technology stack overtime
  • Cost effective scaling - separate subdomains by their resource requirements
  • Segregate regulated software - software development in some domains, such as Software as a Medical Device (SaMD), is regulated but partitioning enables some of an application’s subdomains avoid regulations
  • Segregate highly available components - business critical components should be segregated from less critical components in order to maximize availability

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

There are the following attractive forces that resist decomposition:

  • Simple interactions - simple interactions between components are easier to understand than complex interactions
  • 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 - in order to maximize availability and reduce latency
  • Efficient inter-service communication - lots of network roundtrips and large data transfers can be too inefficient
  • Minimize design time coupling - reduce the likelihood of changing services in lockstep, which reduces productivity

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 dark energy, dark matter and microservices

See these presentations:

Need help wiith microservices?

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


application architecture   architecting   dark energy and dark matter  


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

About Microservices.io

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.

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.

New 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 JUNVCEJE to sign up for $195 (valid until February 1st, 2023). There are deeper discounts for buying multiple seats.

Learn more

Signup for the newsletter


LEARN about microservices

Chris offers numerous resources for learning the microservice architecture.

Training classes

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.


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

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 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.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.



Join the microservices google group

Topics

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

All content


Posts

24 Jul 2017 » Revised data patterns