Building Blocks of Domain Driven Design Part 3 - Services and Modules
Services
A service is an operation offered as an interface that stands alone in the model,without encapsulating state,as ENTITIES and VALUE OBJECTS do. The name service emphasizes the relationship with other objects. A service tends to be named for an activity,rather than an entity.
A good SERVICE has three characteristics:
-
The operation relates to a domain concept that is not a natural part of the Entity or Value Object.
-
The interface is defined in terms of other elements of the domain model.
-
The operation is stateless.
Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance’s individual history.
When a significant process or transformation in the doman model is not a natural responsibility of an Entity or Value Object, add an operation to the model as a standalone interface declared as a Service.Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE.Make the service stateless.
Partitioning Services into Layers
Granularity
This pattern has mainly been used for modelling a concept as a service but the pattern can also be used as a means for controlling granularity in the interfaces of the domain layer as well as decoupling clients from the ENTITIES and VALUE OBJECTS.
Medium grained, stateless SERVICES can be easier to reuse in large systems because they encapsulate significant functionality behind a simple interface.On the other hand fine-grained domain objects can contribute to knowledge leaks from the domain layer into the application layer where the domain object’s behaviour is coordinated. The judicious introduction of domain services can help maintain the bright line between layers.
Modules
The MODULE in a domain layer should emerge as a meaningful part of the model,telling the story of the domain on a larger scale.They can look at detail within a MODULE without being overwhelmed by the whole,or they look at relationships between modules in veiws that exclude interior details.
Low coupling and high cohesion are general design principles that apply as much to individual objects as to MODULES.Low coupling between modules makes it possible to analyze the contents of one module with a minimum reference to others that interact.
High Cohesion of objects with related responsibilities allows modelling and design work to concentrate within the single MODULE.
Letting the MODULES reflect changing understanding of the domain will also allow more freedom for the objects within them to evolve.
Choose modules that tell the story of the system and contain a cohesive set of concepts.This often yeilds low coupling between modules, but if it doesn’t look for a way to change the model to disentangle the concepts or search for an overlooked concept that might be the basis of a MODULE that would bring the elements together in a meaningful way.Seek low coupling in the sense of concepts that can be understood and reasoned about independently of each other.Refine the model until it partitions according to high level domain concepts and the corresponding code is decoupled as well.