Closed bobekhj closed 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.
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:
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.
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.
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?Thank you very much, Hubert