search

zkavtaskin / Domain-Driven-Design-Example

Blog series supplementary domain-driven design C# repository that (hopefully) actually makes sense.
1.75k stars 443 forks source link

Question about DomainEvent and others. #2

Closed bobekhj closed 6 years ago

bobekhj commented 6 years ago

Hi,

Appreciate your work. I've been reading about DDD recently as I have been using old school layered architecture with Anemic Domain Models. If you don't mind, I'd like to ask you some questions. I would greatly appreciate some clarifications.

  1. What is the purpose of "DomainEvents". I see that you are rising some events, for example when Cart is created. Is that used as logger?
  2. In few cases you pass concrete object implementations into functions inside Domain Object. Doesn't it create coupling between them?
  3. Why still need for a service layer? Why not inject repositories into Domain Object? Do you prefer using the service layer as a sort of aggregator to manage Domain Objects and DAL? If so why?
  4. How do you decide which piece of business logic goes into the service and which into the Domain Model?

Thank you very much, Hubert

reddy6ue commented 6 years ago

I'll attempt to answer question 4. here. I'm borrowing from Vaughn Vernon's "Implementing Domain-Driven Design" here. Correct me if I'm wrong.

The logic which belongs entirely in a single bounded context goes in the domain model. The logic which includes integrations between bounded contexts goes into the service layer, thereby preserving the integrity of your bounded contexts.

This probably also answers your "Why still need for a service layer?" part of 3. Injecting repositories into domain objects will create a dependency between your domain and your infrastructure layers, which is a big no-no.

zkavtaskin commented 6 years ago

Hello,

Big thanks to reddy6ue for his answer.

I am going to answer your question in a different order as each answer will build upon each other.

How do you decide which piece of business logic goes into the service and which into the Domain Model? Service layer does number of important things:

  1. Controls unit of work scope (transaction scope management)
  2. Orchestrates domain invocation
  3. Serialization / Deserialization of DTOs
  4. Mapping
  5. Authentication
  6. Authorisation (this depends on your implementation) By doing these things your domain does not have to be polluted.

If business analyst talks about it and cares about it should go in to the domain model, everything else is just supporting. This is easy to say and very hard to do in practice, especially at first. Classifications can help, I found this very useful to help me decouple my thinking: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

What is the purpose of "DomainEvents". I see that you are rising some events, for example when Cart is created. Is that used as logger? Domain events are type of pub/sub pattern (http://www.zankavtaskin.com/2013/12/publish-subscribe-pipeline-pattern-for.html) for your business domain. Your domain events can be synchronous and be part of your unit of work (check out http://udidahan.com/2009/06/14/domain-events-salvation/), or they can be asynchronous by using messaging.

Domain events can be used to send emails, audit domain changes and kick off other business processes. Here is an example of domain event handle: https://github.com/zkavtaskin/Multitenancy-Microservice-FederatedIdentity-Example/blob/master/Server/Domain/Stops/StoppedHandler.cs

Why still need for a service layer? Why not inject repositories into Domain Object? Do you prefer using the service layer as a sort of aggregator to manage Domain Objects and DAL? If so why? Please take a look at the first answer, if it does not answer your question let me know I will elaborate.

In few cases you pass concrete object implementations into functions inside Domain Object. Doesn't it create coupling between them? Please provide some examples.