From:
Invariants, which are consistency rules that must be maintained
whenver data changes, will involve relationships between members of
the AGGREGATE. Any rule that spans AGGREGATES will not be expected to
be up to date at all times. Through event processing, batch
processing, or other update mechanisms, other dependencies can be
resolved within some specified time. But the invariants applied within
an AGGREGATE will be enforced with the completion of each transaction.
a) I interpret this as saying that rule designed to maintain consistency between several Aggregates, doesn’t have to be enforced at the time one of these Aggregates is saving its changes to some persistence storage, but instead can be enforced at some later time when this Aggregate already completes its transaction with persistence storage?
b) But why is such behavior tolerated, since it will lead to inconsistent/corrupt data?
Thank you
a). Correct. An aggregate can be defined as a consistency boundary. Things outside of that boundary, such as other aggregates, are those entities which can be acceptably updated as part of a subsequent transaction. This is eventual consistency.
b). Often times, temporarily stale data is acceptable from the business perspective and should be discussed explicitly. Also, inconsistency actually manifests in places typically regarded as consistent. For instance, as soon as you request data from some service and receive it, the data has the potential to be inconsistent unless there is an ambient transaction. If the requested resource is remote, the transaction will have to be distributed and thus subject to all of the pitfals of 2PC.
Take a look at Udi Dahan’s article on Event-Driven Architecture which discussed eventual consistency from the business perspective.