domain driven design - Can an aggregates invariant include a rule based on information from elsewhere? -

in ddd can aggregates invariant include rule based on information in aggregate? don't think so, causes me problem , don't know how solve it.

i have entity called asset (equipment) i'm modelling root of aggregate. has list of tags (properties) describe things manufacturer, model etc. stores identity of second aggregate called assettype has list of tagtypes, of can marked mandatory.

now appears me 1 of invariant conditions asset should make reference associated assettype enforce non null values in list of mandatory tags. guts crawling thought of how going enforce consistency.

does mean aggregate should comprise 4 entities? if root assettype , had list of assets under it, solve problem, not going fit core use case has other aggregates maintaining lists of different types of asset. asset has root otherwise i'm going have problems.

and assettype can't go inside asset aggregate either. seems absurd.

my guts still says asset , assettype 2 separate aggregates, how resolve consistency problems? or have got invariant wrong?

in scenario, there several methods enforcing invariants.

first of all, consider behaviors around asset aggregate. assume there @ least createassetcommand , removetagcommand. invariants should enforced during execution of these commands in following way:

createassetcommand

since asset associated asset type, assettypeid must provided part of command. id must obtained caller, possibly looking specific asset type. when assettype looked up, corresponding tagtype entities can retrieved, mandatory ones in particular. allow caller construct required tag instances send part of command. note, responsibility of caller provide valid asset type , tags.

removetagcommand

the handler command can retrieve appropriate asset stores assettypeid. next, handler retrieves set of mandatory tags asset type , ensures tags aren't removed. in case, invariant enforced handler itself.

another way handle these invariants introduce eventual consistency, if acceptable. approach, removal of tag asset should publish tagremovedevent. handler event can verify mandatory tag wasn't removed. if was, can create task or notification stating asset in invalid state. note, assumes acceptable asset in invalid state until corrected.

now behaviors around assettype. 1 command compromise integrity of asset aggregate introduction of new mandatory tag. in case, onyl way ensure integrity create appropriate tags each corresponding asset. since can't done automatically, eventual consistency must accepted until appropriate tags provided via manual intervention.

with these approaches, don't have kind of integrity you'd rdms. responsibility of enforcing cross-aggregate invariants delegated command handlers, event handlers , calling code. however, in many instances, kind of consistency acceptable.

take @ effective aggregate design more on this.