Assemblage overview: Part 2 - Defining subdomains

application architecture   architecting   dark energy and dark matter   assemblage  

---

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