Use Cases as a part of Core #752
-
Thanks for this example repository; I like it! I was happy reading the comment in // This Approach: Keep Domain Events in the Domain Model / Core project; this becomes a pass-through
// This is @ardalis's preferred approach
return await _deleteContributorService.DeleteContributor(request.ContributorId); I like the idea that the domain entities, events, and the manipulation logic is wrapped in the Following the
What about using the opposite direction and moving the commands and the command handlers into the The Long story short: the What do you think about it, please? Do you see any drawbacks from your experience? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
In command handlers, it's common to perform tasks beyond the core responsibilities, such as sending emails or interacting with external APIs. These tasks are typically implemented in layers outside the domain. Implementing commands and command handlers directly in the domain layer introduces dependencies from the domain layer to external layers. To maintain the domain layer's independence from outer layers, it's best practice to keep these implementations separate. |
Beta Was this translation helpful? Give feedback.
-
The separation of UseCases from Domain is essentially a way to separate the concerns of the Application from the concerns of the Domain Model. A domain model has no concept of a user or an interaction. It doesn't perform validation of user actions, because it doesn't know anything about users, per se. It's an abstraction that should be divorced from application concerns like workflows or transactions or data-oriented queries that can (and should) bypass the domain model entirely. Think of UseCases as your application services layer. It includes application-specific logic that isn't tied to a particular UI concern. Before pulling it out into a separate project, I would typically add such services (or handlers) in the Web project, because I see the application layer as more closely coupled to the Web project than to the Domain/Core project. That said, if you were to pull the commands, queries, handlers into Core I don't know that you'd have many downsides, aside from just more code and a less "pure" domain model there. Event his could be mitigated with a couple of folders to help differentiate between application and domain model concerns. Probably your biggest risk would be mixing application and domain concerns, which would be easier to do with them sharing the same project. |
Beta Was this translation helpful? Give feedback.
In command handlers, it's common to perform tasks beyond the core responsibilities, such as sending emails or interacting with external APIs. These tasks are typically implemented in layers outside the domain.
Implementing commands and command handlers directly in the domain layer introduces dependencies from the domain layer to external layers. To maintain the domain layer's independence from outer layers, it's best practice to keep these implementations separate.