Retrieves domain entities that have been persisted, performs actions on them, and persists the changes.
Handles both commands and queries.
The "pure" implementation of the domain: entities/models, exceptions, constants, etc. The domain logic should live here because you should avoid anemic domain models, but persistence is not a concern of the domain.
more info is needed
Responsible for connecting the domain with the outside world:
How communication occurs between the domain and the rest of the world. Each of these should be their own process that runs independently.
The process that performs database migrations (database migrations should occur independently in pipelines).
The HTTP API, receiving requests from users, other services, etc. Communicates with the domain exclusively through the Application (via queries and commands due to CQRS).
are Entity Framework contexts a sufficient repository? is having queries in the application unnecessary duplication?
Listens to a Message broker and updates data projections based on events dispatched from other domains.
If you also have topics for commands, they should be their own project because commands are not the same as events.
Listens to a Message broker and performs commands on the domain.
commands are not the same as events.
This may be an implementation detail, but allows for separation of concerns with the other edges.
Uses the outbox pattern to produce events to a Message broker.