Assemblage overview: Part 2 - Defining subdomains

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.

The first step of the Assemblage architecture design process distills the requirements into a set of system operations. A system operation, which is an externally invokable behavior implemented by the application, acts upon (i.e. creates/updates/deletes/queries) one or more business entities (aka. aggregates). The second step of the process defines the subdomains that contain those business entities.

As I describe in more detail below, the key goal of this step is to gather just enough information about each subdomain so that in the next step we can group the subdomains in order services using the dark energy and dark matter forces.

Let’s look at defining subdomains in more detail.

What’s a subdomain?

A subdomain is a team-sized chunk of business functionality, a.k.a. business capability. It consists of the entities/aggregates acted upon by system operations. In Java application, for example, a subdomain consists of Java classes. Collectively an application’s subdomains comprise the application’s domain, which is its area of interest.

A (microservice) is a collection of subdomains

The Assemblage design process considers a microservice architecture to be a partitioning of the application’s subdomains into services. In other words, each service consists of one or more subdomains and subdomain is part of one service.

The grouping of subdomains is determined by the dark energy and dark matter forces

Assemblage uses the dark energy and dark matter forces to group the subdomains into service. The dark energy forces are repulsive forces that force subdomains apart into separate services. The dark matter forces are attractive forces between subdomains that resist decomposition. In order to group the subdomains into services, we need to know about their properties in order to apply the dark energy and dark matter forces. The strength of the dark energy and dark matter forces between a pair of subdomains depends upon the subdomains’ properties.

Gather just enough information to evaluate the dark energy and dark matter forces

It’s important to remember that because we are defining the architecture, we do not need to construct detailed domain models. We only need to do just enough subdomain modelling into order to evaluate the dark energy and dark matter forces.

Let’s first look at what we need to know about each subdomain to evaluate the dark energy forces. After that, we’ll look at what we need to know in order to evaluate the dark matter forces.

Repulsive dark energy forces and subdomains

There are five repulsive dark energy forces that push subdomains apart. The strength of each force between a pair of subdomains depends upon their properties. The following table shows each force and the subdomain properties that affect its strength.

Force Subdomain properties
Simple components Complexity
Team autonomy Ownership
Fast deployment pipeline Complexity and testability
Support multiple technology stacks Technology stack
Segregate by characteristics Characteristics:
  Resource requirements
  Domain-specific software development regulations
  Business criticality
  DDD type

The properties include:

  • Complexity - simple, complicated, complex
  • Ownership - which team owns the subdomain
  • Testability - locally testability
  • Technology stack - required technology stack
  • Resource requirements - e.g. CPU, memory, GPUs, …
  • Domain-specific software development regulations - e.g. HIPAA, PCI, SaMD, …
  • Business criticality - inherited from the system operations that the subdomain implements
  • DDD type - core, supporting, generic

We need to do just enough modeling for each subdomain in order to determine the properties listed in the above table.

Attractive dark matter forces and subdomains: design-time coupling

While most of the dark matter forces arise from the design of system operations, one of the dark matter forces, Minimize design time coupling is concerned with nature of the subdomains themselves. Too avoid tight design-time coupling between services, subdomains that are tightly coupled should be grouped into the same service. The strength of this attractive force between subdomains is proportional to the degree of design-time coupling between them. The degree of design-time coupling depends on how well the subdomain’s API encapsulates its implementation and how much of that API the client subdomain consumes.

Attractive dark matter forces and subdomains: other dark matter forces

The other four dark matter forces are generated by system operations that span multiple subdomains. A system operation acts upon entities/aggregates, each of which is part of a subdomain. For a given operation, the strength of these dark matter forces between a pair of subdomains is determined by each subdomains’ entities and the system operation’s requirements and behavior.

Identifying subdomains

The inputs to this step of the architecture definition process are the application’s requirements and the outputs of the previous step, the system operation specifications and the initial model. The outputs of this step are a description of the subdomains and the revised system operation specifications.

There are numerous ways to identify subdomains. All of them rely on a good understanding of the business. Examples of how you can identify subdomains include:

  • Talking with domain experts to understand the business, and its structure
  • Conducting event storming and using pivotal events and swimlanes to identify candidate subdomains
  • Mapping business capabilities identified by business architects to subdomains

A few things that it’s important to remember about subdomains:

  • They are a model. Subdomains are not like real world islands, for example, that are waiting to be discovered
  • They should primarily be aligned to business concepts
  • They should be (Team topologies) team-sized
  • They should be loosely coupled and highly cohesive
  • Each of the entities/aggregates identified in step 1 should be part of a subdomain

What’s next

In the next article, I describe the concept of a service architecture, which group the subdomains to form collaborating services that implement the system operations.

Need help migrating to microservices?

I’m available to help your organization adopt microservices. I provide consulting and workshops.

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 September 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 WURMXAJV to sign up for $95 (valid until July 19th, 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