Question Details

No question body available.

Tags

domain-driven-design onion-architecture

Answers (2)

Accepted Answer Available
Accepted Answer
April 3, 2025 Score: 6 Rep: 59,765 Quality: Expert Completeness: 30%

As much as it sounds like a copout, the core answer here is that Domain-Driven Design does not tell you how to arrange your Application layer.

At best, it forces your application layer's hand on certain things because of design decisions made in the domain. However, that does not impact what is effectively a method grouping exercise. You know the methods you need, you just don't know which of them to group together (if at all). That's not a technical exercise, it's one of self-imposed categorization.

The basis of your question has me concerned that you're driving your design from the wrong criteria. To that effect, I just want to express as clearly as I can that the domain should be designed without the application layer in mind.

Similarly, the application layer can be designed pretty much without the domain layer in mind, except for minor parts where the application layer is going to have to figure out how to work with the existing domain design.

The users of the program will interact with this aggregate.

Technically speaking, no. The users of the program will interact with your application layer. Your application layer acts as a shield around the domain. It will take the user's interaction and map it to the appropriate domain operation.

How you design your application layer is an artefact of how users will expect to interact with the application (e.g. what do they expect to be able to receive/do?). When that is established, you can build your application layer, and its implementation will be an artefact of how the domain layer has been designed to operate.

Both of these points are really just trying to get across that for the purpose of the question you asked, DDD has no bearing on application layer design.

Nothing in your question reveals a definitive solution to what the best design for your application layer should be. Maybe you want to create different service types for different user roles. Maybe you want to just not group anything at all and implement each operation independently (think CQRS/mediator pattern). Maybe you want to lump the mentioned operations into one class because it's a clearly delineated module within a larger enterprise-grade application.

Your question does not contain the information necessary to make that decision. I suggest you reach out to someone within your organization (or someone who is willing to sit with you and work through it step by step) in order to understand the actual requirements and help draft the technical analysis.

April 3, 2025 Score: 3 Rep: 85,842 Quality: Medium Completeness: 60%

If you have problems organising stuff in DDD often the easy way out is to make Domain Services which act on your AR structs

So here we could have

public class Beverage
{
   list Ingredients
}
public class CoffeeMachineService
{
   Beverage VendBeverage(options) { ....
}
public class CoffeeMachineMaintenanceService
{
   void AddMoreCoffeeBeans(amount) {...
}

This neatly segregates the admin and user functionality while keeping Domain Language names.

Personally I prefer this over the Bounded Context solution, where you would have the same class name but different namespaces

public class UserContext.CoffeeMachine
{
   Beverage VendBeverage(options) { ....
}
public class AdminContext.CoffeeMachine
{
   void AddMoreCoffeeBeans(amount) {...
}

I feel that this just gets confusing, someone says "The coffee machine should do this.." in a meeting and you have to clarify the context, and then explain DDD etc which just goes against the whole point of DDD matching the code to the business language in my opinion.