In DDD can an aggregates invariant include a rule based on information in a another aggregate? Now I don\'t think so, however this causes me a problem and I don\'t know how to
In this scenario, there are several methods for enforcing invariants.
First of all, consider the behaviors around the Asset
aggregate. I assume there is at least a CreateAssetCommand
and a RemoveTagCommand
. The invariants should be enforced during execution of these commands in the following way:
CreateAssetCommand
Since an asset is always associated with an asset type, an AssetTypeId
must be provided as part of this command. This ID must be obtained by the caller, possibly by looking up a specific asset type. When AssetType
is looked up, the corresponding TagType
entities can also be retrieved, the mandatory ones in particular. This will allow the caller to construct the required Tag
instances to send as part of the command. Note, it is the responsibility of the caller to provide a valid asset type and tags.
RemoveTagCommand
The handler for this command can retrieve the appropriate Asset
which stores the AssetTypeId
. Next, the handler retrieves the set of mandatory tags for the asset type and ensures that those tags aren't removed. In this case, the invariant is enforced by the handler itself.
Another way to handle these invariants is to introduce eventual consistency, if acceptable. With this approach, removal of a tag from an asset should publish a TagRemovedEvent
. A handler for this event can then verify that a mandatory tag wasn't removed. If it was, it can create a task or notification stating that an Asset is in an invalid state. Note, this assumes that it is acceptable for an asset to be in an invalid state until something is corrected.
Now to behaviors around AssetType
. One command that could compromise the integrity of the Asset
aggregate is the introduction of a new mandatory Tag
. In this case, the onyl way to ensure integrity is to create appropriate tags for each corresponding asset. Since this likely can't be done automatically, eventual consistency must be accepted until appropriate tags are provided via manual intervention.
With all these approaches, you don't have the kind of integrity you'd get with a RDMS. The responsibility of enforcing cross-aggregate invariants is delegated to command handlers, event handlers and calling code. However, in many instances, this kind of consistency is perfectly acceptable.
Take a look at Effective Aggregate Design for more on this.