We continue our series in the chapter 7 of IDDD which talks about Services 😁
A. The problem ⚠️
In the blue book, it says :
There are important domain operations that can't find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things, but since our modeling paradigm is objects, we try to fit them into objects anyway. Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming. But when we force an operation into an object that doesn't fit the object's definition, the object loses its conceptual clarity and becomes hard to understand or refactor. Complex operations can easily swamp a simple object, obscuring its role. And because these operations often draw together many domain objects, coordinating them and putting them into action, the added responsibility will create dependencies on all those objects, tangling concepts that could be understood independently.
So here is the problem, we have some operations but they can not be put inside an Entity or a Value Objects , how to deal with those operations ?
B. The Solution 🤔
The solution is to create some doers, and the book says :
Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation. These "doers" end up with names ending in "Manager" and the like. They have no state of their own nor any meaning in the domain beyond the operation they host. Still, at
least this solution gives these distinct behaviors a home without messing up a real model object.
C. Service 😌
Before giving the definition of the book i want to emphasize the fact that this term is proper to DDD and is not equal to the way we put a suffix to some classes in our java or typescript projects for example, it is a conceptual thing :
In the blue book :
A SERVICE is an operation offered as an interface that stands alone in the model, without encapsulating state, as ENTITIES and VALUE OBJECTS do. SERVICES are a common pattern in technical frameworks, but they can also apply in the domain layer.
In the red book :
A Service in the domain is a stateless operation that fulfills a domain-specific task. Often the best indication that you should create a Service in the domain model is when the operation you need to perform feels out of place as a method on an Aggregate or a Value Object.
D. Domain Service is not an Application Service 🤨
Because when we see the big picture of domain driven design the line between the application and the domain is thin, and so the concept of service is different between the two :
Don’t confuse a Domain Service with an Application Service. We
don’t want to house business logic in an Application Service, but we do want business logic housed in a Domain Service. Briefly, to differentiate the two, an Application Service, being the natural client of the domain model, would normally be the client of a Domain Service.
N.B : For example in a banking application, if the banking application can convert and export our transactions into a spreadsheet file for us to analyze, that export is an application SERVICE. There is no meaning of "file formats" in the domain of banking, and there are no business rules involved. On the other hand, a feature that can transfer funds from one account to another is a domain SERVICE because it embeds significant business rules (crediting and debiting the appropriate accounts, for example) and because a "funds transfer" is a meaningful banking term.
E. GOOD Domain Service
There is three characteristics :
The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.
The interface is defined in terms of other elements of the domain model.
The operation is stateless.
N.B : Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance's individual history. The execution of a SERVICE will use information that is accessible globally, and may even change that global information (that is, it may have side effects). But the SERVICE does not hold state of its own that affects its own behavior, as most domain objects do.
F. Repartition of services 💭
In this picture you can see where each service belongs to :
Conclusion : To conclude we can say , SERVICE, the pattern is also valuable as a means of 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. Also, fine-grained objects can lead to inefficient messaging in a distributed system.
See you next time 😁
Top comments (0)