A better solution is to have an application service retrieve the information required by an entity, effectively setting up the execution environment, and provide it to the entity. Another reason is that is makes reasoning about the behavior of entities more difficult since the Single-Responsibility Principle is violated. One reason for this is because it requires the plain-old-(C#, Java, etcвЂ¦) objects implementing entities to be part of an application dependency graph. One solution is to inject repository dependencies directly into the entity, however this is often frowned upon. A common problem in applying DDD is when an entity requires access to data in a repository or other gateway in order to carry out a business operation. As such, it is a convenient point to inject various gateways such as a repository or wrappers for external services. However, the specifics of the communication with durable storage mechanisms are handled in the infrastructure layer.ДЄn application service has an important and distinguishing role - it provides a hosting environment for the execution of domain logic. The interface is declared in the domain layer and is an important aspect of the domain. A repository implementation is also an example of an infrastructural service. The domain layer doesnвЂ™t care about the specifics or how an event notification is delivered, it only cares about raising the event. Another infrastructural service can handle the same event and send a notification via SMS or other channel. An email infrastructure service can handle a domain event by generating and transmitting an appropriate email message. The concept of the event exists in the domain layer and the domain layer determines when the event should be raised. For example, a common application requirement is the sending of an email notification informing interested parties about some event. Infrastructural services are instead focused encapsulating the вЂњplumbingвЂќ requirements of an application usually IO concerns such as file system access, database access, email, etc. This can become an anti-pattern because the information expert aspect of OOP is lost.Дomain services are different from infrastructural services because they embed and operate upon domain concepts and are part of the ubiquitous language. On the other end of the spectrum is over-utilization of domain services leading to an anemic domain model in what essentially becomes a separation of data, stored in entities, and behaviors, provided by the service. Domain services are often overlooked as key building blocks, overshadowed by focus on entities and value objects. These types of services can be identified more specifically as domain services and are part of the domain layer. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Beyond this implication are usually assumptions of statelessness and the idea of pure fabrication according to GRASP.Д®ric Evans introduces the notion of a service as a building block within Domain-Driven Design in the blue book: Another characteristic of a service operation is that of input and output - arguments and provided as input to an operation and a result is returned. First and foremost, a service implies a client the requests of which the service is designed to satisfy. In all these cases the term вЂњserviceвЂќ is valid, however the roles are different and can span all layers of an application.ДЄ service is indeed a somewhat generic title for an application building block because it implies very little. As a result, there is a cloud of confusion surrounding the notion of services as one tries to distinguish between application services, domain services, infrastructural services, SOA services, etc. The term service is overloaded and its meaning takes on different shades depending on the context. UPDATE: Vaughn Vernon provided some very valuable insight into the differences between application services and domain services as well as emphasizing the Hexagonal architectural style.

Ddd domain driven design