Question

Or should I always get my entities via service methods?

Thanks

Answer 1

Most of the time I try to separate my layers as much as possible. Usually I’ll have my services act as facades to the business logic. Within business logic I use a DI Container, like Unity, to resolve my repositories…

Example:

IUnityContainer container = IoCManager.Container;
using (var repository = container.Resolve<IRepository<Token>>())
{
    return repository.Eagerly(f => f.Fetch<TokenSetting>(t => t.Settings))
                     .Where(t => t.Value == tokenGuid && t.Expired == null)
                     .FirstOrDefault();
}

My business logic contains no dependencies now on my infrastructure layer (repositories). For a great Repository implementation take a look at NCommon. Ritesh Rao wrote some great examples of pattern usage for DDD.

Whether it’s wrong to reference your repositories is subjective. I think DDD purists will tell you it most likely is. “How much SoC are you trying to achieve” is the real question. It’s usually best to strive for high cohesion via loose coupling, but sometimes that can be overkill.

Hope this helps.

---

[EDITED]

Repositories can exist within the domain. Really they sit in between your business logic / model and your infrastructure model. You are correct to depend on the interface not implementation.

Look at Martin Fowler’s – Separated Interface Pattern. In my above example I depend on the interface. The DI container resolves the actual implementation of my concrete repository class. Here is a sample DDD diagram I’ve been refining as I learn.