about your first point: it really comes down to requirements analysis and domain modeling. Why do you want to prevent deletion of a record? Is it because users make mistakes? Is it because you might throw away aggregates that you might need? You should try to find out the underlying reason for preventing someone to delete an aggregate. And if this relationship does seem to be so important, you might be putting an aggregate boundary in the wrong place.
If you really want to prevent deletion of an aggregate that has references, you could either require the client to check for references (using the query database), or make sure that the aggregate (that is not to be deleted) keeps track of the incoming references. This would require a saga-like implementation (i.e. an event listener that notifies the aggregate of 'incoming references). Your domain expert’s language should give away some hints about this.
If we have a product where it can be sold by modules. We would need a system where business logic can be pluggable.
Let say for example, we’re trying to model a laboratory, where job might comes in into the lab.
If the product customer is a commercial laboratory, they will want to buy an invoice module.
I think it’s fair to say that job and invoice are two separate bounded context.
Without the invoice module, when job is cancelled, we would want to remove the job from the system.
But when there’s an invoice module, the system shouldn’t allow job to be removed, if there’s an associated financial informations (e.g. unpaid invoice).
I guess, I’ll just have to use application event for event collaboration.
In the end, it’s about applying DDD properly and choosing consistency boundaries wisely.
I agree. I think it would be interesting to hear how would the other solve this issue.
Unfortunately, the application becomes more complex due to sales decision.
About your second point: I don’t see how this is any different than when you would not be using CQRS. You would just have a component that reads from the external file (using the pluggable system you’re referring to) and sends commands into your system.
I agree, although if I can make the same philosophy applied everywhere in the system. E.g. using command and events, it would make the system feels consistent.