Questions regarding Domain driven Design

Question

After reading Eric Evans' Domain driven Design I have a few questions. I searched but no where i could able to find satisfying answers. Please let me know if anyone of you have clear understanding below questions.

My concerns are

1. Repository is for getting already existing aggregates from DB,Web service . If yes, Can Repository also have transaction calls on this entity (i.e Transfer amount,send account details ...etc)

2. Can Entity have Methods which have business logic in which it calls infrastructure Layer services for sending emails .. logs etc (Entity methods calling IS services direclty).

3. Repository implementation and Factory classes will reside in Infrastrucure Layer. is that correct statement ?

4. Can UI layer (controller) call Repositry methods directly ? or should we call these from Application layer ?

There are still lot many confusion in my mind ... please guide me ... Books i am using Eric Evan's domain driven desing ...... .NET Domain-Driven Design with C#

Phlox

Answer 1

1. There is a lot of debate about whether Repositories should be read-only or allow transactions. DDD doesn't dictate any of these views. You can do both. Proponents of read-only Repositories prefer Unit of Work for all CUD operations.

2. Most people (self included) consider it good practice that Entities are Persistent-Ignorant. Extending that principle a bit would indicate that they should be self-contained and free of all infrastructure layer services - even in abstract form. So I would say that calls to infrastructure services belong in Service classes that operate on Entities.

3. It sounds correct that Repository implementations and Factories (if any) should reside in the infrastructure layer. Their interfaces, however, must reside in the Domain Layer so that the domain services can interact with them without having dependencies on the infrastructure layer.

4. DDD doesn't really dictate whether you can skip layers or not. Late in the book, Evans talks a bit about layering and calls it Relaxed Layering when you allow this, so I guess he just sees it as one option among several. Personally I'd prefer to prevent layer skipping, because it makes it easier to inject some behavior at a future time if calls already go through the correct layers.

Porism

From my point of view there's something wrong with the statement 3. The factory responsibility is to create entities, so if the factory resides in the Persistence layer then the entity also has to reside in the persistence layer (otherwise the dependency inversion principle would be broken - it is not enough for the factory to know an abstraction of the entity, it needs to know the concrete implementation). But how could the entity implementation reside in the Persistence layer? The entity is not a DTO, it contains a lot of domain logic! – Nicobarese

Perhaps these detailed explanation will help: https://mcmap.net/q/15620/-ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-application-39-s-entry-point blog.ploeh.dk/2013/12/03/… – Porism

Answer 2

1. Personally, in my latest DDD-project, I use a Unit Of Work that holds an NHibernate session. The UoW is ctor injected in the repositories, giving them the single responsible of Add, Remove and Find.

2. Evans has stated that one piece of the puzzle that's missing in the DDD book is «Domain Events». Using something like Udi Dahan's DomainEvents will give you a totally decoupled architecture (the domain object simply raises an event). Personally, I use a modified version of Domain Events and StructureMap for the wiring. It works great for my needs.

3. I recommend, based on other recommendations, that the Repository interfaces be a part of the model, and their implementations be a part of the infrastructure.

4. Yes! I've personally worked on three DDD web projects where services and repositories were injected to the presenters/controllers (ASP.NET/ASP.NET MVC) and it made a lot of sense in our context.

Personalty

Thanks Martin, for your suggestions ...... i think i have to start implementing the design instead of thinking lot of DDD , i assume my Domain design will get manu iterations once i start building the application – Phlox

I agree with the idea of the repository interfaces in the domain model and the implementations in the persistence layer, but what about the factories? – Nicobarese

Answer 3

1. The repository should only be for locating and saving entities, there should not be any business logic in that layer. For example:

   repository.TransferAmount(amount, toAccount); // this is bad

2. Entities can do things like send emails as long as they depend on abstractions defined in your domain. The implementation should be in your infrastructure layer.

3. Yes, you put your repository implementation in your infrastructure layer.

4. Can UI layer (controller) call Repositry methods directly ? or should we call these from Application layer ?

Yes, I try to follow this pattern for the most part:

[UnitOfWork]
public ActionResult MyControllerAction(int id)
{
    var entity = repository.FindById(id);
    entity.DoSomeBusinessLogic();
    repository.Update(entity);
}

Magdau