Use Cases as a part of Core

[dsenkyr]

Thanks for this example repository; I like it!

I was happy reading the comment in DeleteContributorHandler:

// 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 Core project.

---

Following the README of the UseCases project:

…the Use Cases project can be omitted, and its behavior moved into the UI project, either as separate services or MediatR handlers, or by simply putting the logic into the API endpoints.

What about using the opposite direction and moving the commands and the command handlers into the Core project? Then, the manipulation logic is wrapped in the Core project. Command handlers could be internal at the level of the Core project.

The Web project will still send the commands; however, this time, the actions that are possible to do in our domain are defined in the Core project.

Long story short: the Core project defines the domain and the available actions in the domain (and handles them); the Web project serves as the public API and uses the commands from the Core project.

What do you think about it, please? Do you see any drawbacks from your experience?
Thank you!

[ParsaMehdipour]

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.

[dsenkyr]

I see your point about the external layers, thank you!

For complex tasks in the domain, we can have a domain service in the Core project that does not operate outside the bounds of the domain. A possible pre-requisite in the sense of interacting with external API could be handled outside the domain, and the result could be propagated to the domain handlers as input if needed.

For completeness, in this example repository, there is the IEmailSender interface declared in the Core project because it's used in the ContributorDeletedHandler notification handler. The domain defines which dependency is needed and the realization is implemented outside the domain. I think this approach was chosen primarily because the domain event is handled in the domain project.

[ardalis]

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.