Home/ Questions/Q 1052429
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T17:05:32+00:00

I’ve been working with S#arp Architecture but this can probably be applied to any

  • 0

I’ve been working with S#arp Architecture but this can probably be applied to any DDD architecture (Domain / Core, Application Services, Infrastructure, and Presentation).

There are many ASP.NET MVC examples that show the controller operating on the domain model through repository interfaces. In fact, the S#arp Architecture tutorial has the StaffMembersController referencing IStaffMemberRepository where it calls FindAllMatching (implemented in the repository). The StaffMember entity, also in the domain/core layer, looks like a data bag with properties and minimal validation on the properties.

Let’s say you have a controller that is getting bloated with things that look like business concerns. After reading Microsoft’s “Designing Business Entities” chapter in Microsoft’s Application Architecture Guide, I believe these concerns could be called “Domain Services”.

I want to put these domain services in the domain/core layer but I’m not sure where they should go. Should I create a services folder in the domain/core project that hosts interfaces with an implementations folder underneath it? That seems like a good approach, but I want to see how others have handled this.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What you’re calling Domain Services in your question are what I would call Application Services. This kind of confusion over the three different types of service (application, domain and infrastructure) is what lead to the term “Tasks” being used in Who Can Help Me? (instead of application services).

    Broadly speaking, I see domain services as actions/behaviours within the domain that don’t belong to any single entity – this is pretty much as described in the Evans DDD book. Application services are more of an orchestration layer/facade over the domain that allows an application to interact with the domain without needing to know the full detail about how it works.

    So I believe you need an application services layer to remove the bloat from your controllers. This is the approach that’s shown in WCHM and it’s the one I now follow in my apps.

    In terms of where they should live – I’d send to say you should have them in their own project. If you’re being purist about it, the contracts should also live in their own assembly, which means that if you like, you can remove all knowledge of the domain from your controllers. However, the WCHM approach places the contracts in the Domain project, and allows the controllers to have knowledge of the entities. Some people complain about this but it’s basically just a compromise.

    Hope this helps
    Jon

    • 0