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
- Domain services model core business domains vs other types of service oriented architecture which focus on layer, system or no-particular orientation
- 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
- 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
- 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
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 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
- Monolithic domain service
- Provider backed domain service
- Provider backed domain service with read-store
- Self-contained domain service
Provider backed Domain Services
Provider backed domain services with read-store
Self-contained domain service
There is no COTs system as the master, this domain service is the master with the business logic
Monolithic Domain Service
Service Design Patterns
There are 3 core patterns when building domain services
- Monolithic Service: Single endpoint, large canonical data model, coupled contexts across different domains (SOA)
- Explicit context, common services : Mono-repo with multiple teams from different domains and contexts in a single common service
- 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
- Domain services function as a core business domain service
- If the domain boundaries are not clear, then a large domain monolithic service can emerge coupling multiple teams
- 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
Alok Mishra 