I read .NET Domain-Driven Design with C#: Problem - Design - Solution and I noticed that the author created a domain service for each aggregate root.

However, the domain services were only facades to the corresponding repository. For example this is a code sample from the application from his book

public static class CompanyService
    private static ICompanyRepository repository;
    private static IUnitOfWork unitOfWork;

    static CompanyService()
        CompanyService.unitOfWork = new UnitOfWork();
        CompanyService.repository = 

    public static IList<Company> GetOwners()
        return CompanyService.GetAllCompanies();

    public static IList<Company> GetAllCompanies()
        return CompanyService.repository.FindAll();

    public static void SaveCompany(Company company)
        CompanyService.repository[company.Key] = company;

    public static Company GetCompany(object companyKey)
        return CompanyService.repository.FindBy(companyKey);

As you see almost all calls to the services are wrappers to repository calls. Is this a good pattern when building domain services?

Should we always wrap our repositories in domain services? Is there a better approach?

  • What do you mean by "better"? Feb 21, 2013 at 19:02
  • The question I would be asking myself here is "what value does the CompanyService provide over the CompanyRepository?". If the answer is none the class is a middle-man - delete it, mercilessly!
    – MattDavey
    Feb 21, 2013 at 19:41
  • @MattDavey well in this code sample I can see that the repository methods were translated to domain calls. For example, GetAllCompanies() wraps repository.FindAll(). However, why can't I just create a repository method repository.GetAllCompanies() instead?!
    – Songo
    Feb 21, 2013 at 21:17
  • @Songo: Depends on whether every other method in your Service Layer also similarly wraps a repository method call. Feb 21, 2013 at 22:56

2 Answers 2


A repository is meant to be an abstraction for your data store, and generally provides data-retrieval capabilities. This arrangement allows you to, for example, change out the data store for some different datastore (say, from Oracle to SQL Server, although in practice this rarely happens), and your repository API should still work, if you didn't expose any implementation-specific details.

A service layer, on the other hand, is an API meant to be consumed by some outside user or agent, and provides services, not data retrieval per se (although it can do that). A Service API might draw on multiple repositories, and perform transforms on the data before serving it to the client. It might wrap the data into custom objects, or provide paging abilities. You can do things in your service layer beyond simple data storage and retrieval.

If you don't have the need to provide an additional layer of abstraction beyond what your Repository provides, you might not need a Service Layer at all.

  • 1
    +1 One thing caught my attention in the code I posted. The SaveCompany method marks the unit of work. If I was solely using a repository would the call to commit all changes be in the repository?
    – Songo
    Feb 23, 2013 at 1:03
  • Yes, it would... Feb 23, 2013 at 3:52

As your application grows, there are complex operations that your service layer can wrap and expose. It's really a facade over the domain model. For instance in a sales app, you might not care about the line item as a discrete object within the model. You just want to add items to a cart, check them out, and print an invoice for the user after any discounts are applied.

Behind the scenes there are probably dozens of objects involved in the interaction. The service might project a flattened view of the object model so that as the domain model changes behind the scenes, the client is not impacted by those changes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.