Why the domain event handler in the Application and not Domain

[idan-h]

Hey, I have a question

If the purpose of the domain events are for in process events, why not include the event handlers in the domain?
This way you wouldn't be able to create new instance for the db context, etc... It will all be a part of the domain

[PilotBob]

Application is part of Core but specific to this application. The domain is generic and could possibly work with many applications. The domain publishes events but it's up to each application to determine how or if it wasn't to handle those events.

At least, this is my understanding of layering here.

In Ardali's template, what's in App/Domain here is in a single Core project. So, he does have the Entities, the Events, and the Domain Event Handlers in the same project. If you don't share the domain with other apps, this works just as well.

[DennisJansenDev]

You could have a public API application layer and a private one.

[PilotBob]

How about an online web store (public facing), a POS system, and a customer support app (store employees). All three would use the same domain, but be different apps that might handle events differently, or not at all.

[peter-vndrhvn]

If we had a public and private API that share the same domain... Or an online web store and customer support app that both use the same domain entities and configuration. How exactly could I share this domain? Would it be a good idea to include both APIs in the same solution and have 2 application layers (one for each API)? Thank you for your insights.

[PilotBob]

Just musing. You could do it that way. Have multiple applications in the same solution. Or, you could publish your domain project to a nuget feed and pull it into the other app that's in it's own solution.

I think you would probably want to share much of the infrastructure shared too. At least the persistence parts. Put the infra you want to share into their own project and include that in the nuget package as well, or a separate one.

You could also, it talking about APIs have 1 application and two presentation projects. Or, even 1 API project which includes both the private and public endpoints. Of course, that depends on physical deployment as well. If your private API is physically behind your firewall that would probably require two apps, or at least two presentation layers.

I personally like to have 1 repo equal one unit of deployment. So, if I deployed the web app separately from the API, I'd want them as separate solutions. If they are always deployed/versioned together having them in the same sln/repo seems fine.

I don't think there's one right way.

[peter-vndrhvn]

Thanks a lot, this is very helpful. Having a separate infrastructure persistence layer and share that along with the domain layer seems like a good idea (at least in my case).