application architecture   architecting   dark energy and dark matter   assemblage  

Assemblage overview: Part 2 - Defining subdomains

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.


application architecture   architecting   dark energy and dark matter   assemblage  


Copyright © 2024 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 organizations improve agility and competitiveness through better software architecture. Learn more about his consulting engagements, and training workshops.

Upcoming public talks/workshops

PREMIUM CONTENT

Premium content and office hours is now available for paid subscribers at premium.microservices.io.

MICROSERVICES 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 more

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

Remote consulting session

Got a specific microservice architecture-related question? For example:

  • Wondering whether your organization should adopt microservices?
  • Want to know how to migrate your monolith to microservices?
  • Facing a tricky microservice architecture design problem?

Consider signing up for a two hour, highly focussed, consulting session.

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 ILFJODYS to sign up for $95 (valid until March 12, 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 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

GitOps   ·  Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  books   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  deployment pipeline   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  generative AI   ·  glossary   ·  health   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service blueprint   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  testing   ·  transaction management   ·  transactional messaging

All content


Posts

24 Jul 2017 » Revised data patterns