I have to have one application layer for all the projects or one application layer for each project?

I have a project with various bounded contexts. I have Purchases bounded context and product bounded context.

The two projects are developed by two diferent persons, so I am organazing the projects in this way:

• MyProject.Products.Domain

• MyProject.Products.Repository

• MyProject.Products.Comun

• MyProject.Products.Application

• MyProject.Products.Service.Server.Grpc

• MyProject.Products.Service.Client.Grpc

• MyProject.Purchases.Domain

• MyProject.Purchases.Repository

• MyProject.Purchases.Comun

• MyProject.Purchases.Application

• MyProject.Purchases.Service.Server.Grpc

• MyProject.Purchases.Service.Client.Grpc

In the ASP project I add the two services to can connect remotely. But this ASP project doesn't have any other functionality than to can connect from the outside. So there is no logic to can communicate one project with the other.

But sometimes, the action in one bounded context, affects to another bounded context. In this case, I have read that one option it is to use domain events. But for that, I guess I need a layer higher than the domain that can access to the two domains, receive the event from one domain and notify to the other domain.

Perhaps this layer could be the application layer, but in the way I am organazing my project, it is not possible, because each bounded context has its own application layer. Perhaps should I have only one application layer for all the projects? Something like this:

• MyProject.Application

• MyProject.Products.Domain

• MyProject.Products.Repository

• MyProject.Products.Comun

• MyProject.Products.Service.Server.Grpc

• MyProject.Products.Service.Client.Grpc

• MyProject.Purchases.Domain

• MyProject.Purchases.Repository

• MyProject.Purchases.Comun

• MyProject.Purchases.Service.Server.Grpc

• MyProject.Purchases.Service.Client.Grpc

In this case, the application layer could connect the two bounded contexts, but the, this application will have to provide all the functionality of all contexts, so it could be very big.

This makes me think too what happen with the repositories, should I have only one for all the projects? Because I need that when one context affects to another, it should be a transaction, a unit of work.

So in sumary, I have two main questions, how to organize the projects and how to ensure the unit of work when one context affects to another context.

Thanks.