What is the service layer in DDD?

Question

Reading about Ddds I’ve heard about the service layer and I’m having a little doubt about that because from what I read a service can count business logic. Basically the definition I saw is this:

Services are classes that contain business logic but do not belong to any Entity or Objects of Values. It is important to emphasize that Services do not keep status, that is, every call to the same service, given the same pre-condition, must always return the same result.

In another text I read that there are three types of services: application services, infrastructure services and domain services, and the type of service that we are dealing with in the DDD services layer are domain services.

What leaves me in doubt is the fact that such services contain business logic. Shouldn’t the business logic be completely contained in the domain types? What these domain services really are and how we can identify them?

Answer 1

In DDD, business logic should not be completely contained in domain types?

Yes. And, in Ddds, Services are in fact domain objects.

In DDD, Services are not a layer but a kind of business object.

What these domain services really are and how we can identify them?

The way to identify them is in your quote, but I would write differently:

In Ddds, Services are objects that contain business logic that does not naturally belong to any Entity.

The difference between my statement and your quote is that I took the comma and the "but". There is no "but/however/however/however" in the definition of Services. They are simply what they are. I also took the "business logic that does not belong to Valuables" because Valuables never have a business rule.

How to choose where a business logic should reside

Visualize a business rule and identify which entity it belongs to. The question to ask is: "which entity should have this behaviour?" If you cannot determine and the design is ok, then this business rule belongs to a Service and not to an Entity.

Eventually a business rule appears to belong to an Entity, but will affect several entities of that type and not just a single instance - in this case the business logic also belongs to a service.

Entity Behaviors

See this business rule:

• Download a receivable that was paid today.

If you have an entity Contareceber, this business logic belongs to this entity. You obtain the meaning of this entity and invoke its behavior download:

ContaReceber contaReceber = contaReceberRepo.get(contaId);
contaReceber.baixaPorQuitacao(dataReferencia);
contaReceberRepo.persist(contaReceber);

Behaviors of Services

Look at this other business rule:

• Expunging irrecoverable receivables.

A receivable has no way of knowing that it is uncollectible. To know which accounts are uncollectible, you need to get the parameters from somewhere. These parameters will, for example, be accounts that have been overdue for more than five years without any interest from the client in trading. The knowledge contained in several other entities is required to find out which payables meet this criterion.

This business rule naturally does not belong to any Entity, so it belongs to a service, which would be, for example:

ServicoBaixaAutomatica servicoBaixaAutomatica = BaixaAutomaticaService.get();
servicoBaixaAutomatica.expurgarIncobraveis(dataReferencia)

Complementing

Business or domain objects, in DDD, do not constitute layers; on the contrary, they all reside in the same layer, the business layer (of course), usually called Domain.

The DDD layers are:

• Interfaces: is the interface of the system to the outside world. It can be for example a graphical user interface or a service facade.
• Application: contains the mechanics of the application, directs to business objects the interactions of the user or other systems.
• Domain: layer where the business objects reside (Entities, Value Objects, Aggregations, Services, Factories, Repositories).
• Infrastructure: supports the other layers, for example by providing mapping between business objects and databases and access services to these databases.

Answer 2

Making logic out of domain types allows the application of a design pattern known as MVC (MOdel-View-Controller) where the model is responsible for the implementation data, the view is the graphical interface that the user interacts with, and the) controller(s) is(are) the logical part of the application itself.

The flow of a user action in this design pattern is this way:

1. User interacts with view. (Informs values and sends them through a form, for example)
2. The view mounts an object with the user-informed values and sends it to the controller. (A query request in a BD, for data of a specific person)
3. The controller then executes the order and reaps the results.
4. The controller makes changes to the model, if necessary, or collects data from it regarding the order result.
5. The controller returns these results to the view. (Returns the model objects that are equivalent to the query in the BD)
6. The view then displays the form results on the screen. (Returns a table with the data recovered by the query)

Domain services can be easily identified as the functional requirements of their application.