@Allard, I think about modelling the entities as CQRS as well. Althought they are CRUD, the have influence to the Root Aggregates.
My Resaon (Example):
RootAggregate “Issue” belongs to a “Category” and a “Project”. “Category” and “Project” are basically “CRUD” entities without domain logic.
An “Issue” can be assigned to a “Project”. When a Project gets deleted, all Issues will be deleted (using commands). When a Category is deleted, all Issues are assigned to a default category (or none).
Another reason is that the developers who use the backend have to deal only with one concept, not with mixed concepts.
So if Project and Issue are Aggregate Roots, how would I reference them? E.g. a AssignIssueToCategory command would contain the UIDs of both aggregates. Would Issue now simply have a property “CategoryID”?
How would I implement a DeleteCategory command handler? Normally I implement command handlers in the aggregates. Which would be responsible in handling the command? Would Category notify all it’s Issues? In this case it must maintain a list of it’s issues. Would the command trigger some other commands (within the same transaction)? Or should I use a saga here?