Domain Service Design and Patterns

Domain services implement core logic for a business domain and are a relied upon by experience and consumer services. Domain services can be self contained and store the business logic and state or rely on an external provider system (translating from a “raw system format” to a “canonical” domain format)

In this post we look at some of the types and design patterns for domain services especially around the monolithic-database services and the SOA-type domain services

Looking at these types and design patterns should help you and your team identify the type of domain service you are building, recognise some of the constraints in delivering business value and hopefully you can start to balance coupling and cohesion in your services better!

This is a longish post, so for those in a hurry – here are the key takeaways from this post

  1. Domain services model core business domains vs other types of service oriented architecture which focus on layer, system or no-particular orientation
  2. Domain services are about not leaking internal context out, so boundaries are important. If your service design teams knows about client contexts or clients know about your implementation details then the boundaries are not clear, leading to confused software
  3. Going too broad with coarse domain services creates challenges with software that is used in multiple contexts leading to poor experience, data quality, change autonomy etc
  4. Going too fine grained with domain services is a problem too, especially if multiple small services couple to each other and get chatty. This can create a hair-ball (cyclic graph)

Domain Services: Wide context

Domain services provide an implementation over the core business functions for a particular domain, for example Order, Shipping, Customer, Identity, Document etc.

Domain services provide an API for Commands (create/update) and Queries (Search, Get by ID) using a Domain Model. This model is key as it is the representation of the business model of the domain to external services. The domain model is determined through design processes such as Domain Events or Domain Storytelling using the Domain Driven Design (DDD) technique

Domain services also publish Domain Events which are emitted in a domain language and often notify subscribers of a change in the state of a domain object

A hypothetical C4 context model of a business with a Customer, Experience Channels, Experience Services, Domain Services and Systems

Commands, Queries, Events for State transfer

Domain services provide APIs for Commands and Queries and emit events called Domain events. These operations manage the state of a domain resource (HATEOS anyone?)

Commands on a resource enable the state transition, for example POST, PUT, PATCH. Queries enable the consumers to read the information about the current state, for example GET. Commands on a collection help us to search, add or remove items and Queries on a collection help search and list specific items by an identifier

Domain events are emitted on specific state changes. State transitions are done via operations in the API

Domain events are emitted on all or specific state changes, for example “OrderCreated”, “OrderSubmitted” or “OrderCancelled” and as you can imagine subscribers for these order domain events would be Shipment Domain service or Payment domain service

Types of Domain Services

  1. Monolithic domain service
  2. Provider backed domain service
  3. Provider backed domain service with read-store
  4. Self-contained domain service
Provider backed Domain Services
Provider backed domain service. The state is managed in the external system

Provider backed domain services with read-store

Provider backed domain services with read-store. State is in the external system, query can be in the domain service driven by events from external system

Self-contained domain service

There is no COTs system as the master, this domain service is the master with the business logic

Self-contained Domain services

Monolithic Domain Service

Monolithic database behind two or more domain services.

Service Design Patterns

There are 3 core patterns when building domain services

  1. Monolithic Service: Single endpoint, large canonical data model, coupled contexts across different domains (SOA)
  2. Explicit context, common services : Mono-repo with multiple teams from different domains and contexts in a single common service
  3. Explicit context, unique service: Micro or Coarse-grained services with multiple contexts owned by the same team for a single domain service

Monolithic service

Explicit context, common service

Explicit context, unique service

Conclusion

In conclusion, we saw how domain services provide APIs for Commands and Queries over domain resources and publish Events on specific state changes in a domain language

There are 3 key takeaways from this post

  1. Domain services function as a core business domain service
  2. If the domain boundaries are not clear, then a large domain monolithic service can emerge coupling multiple teams
  3. Fine-grained domain services can be monolithic if the provider system or the database model used by the domain service is shared across other services

Unknown's avatar

Published by alokmishra

Alok brings experience in engineering and architecting distributed software systems from over 20 years across industry and consulting. His posts focus on Systems Integration, API design, Microservices and Event driven systems, Modern Enterprise Architecture and other related topics

Leave a Reply