Comparison
AggregatevsBounded context
Aggregate
you can change these five objects together in one transaction, and anything outside them has to wait its turn.
A cluster of objects treated as one unit for changes, with a boundary that defines what must be consistent immediately. It is the pattern that decides transaction scope and lock scope, so it is a performance and concurrency decision as much as a modelling one. Making aggregates too large is the standard mistake, and it shows up as contention rather than as anything a modeller would notice.
Full entry →Bounded context
'customer' means one thing to billing and something else to support, and the shared table forces one of them to be wrong.
A boundary inside which a term has exactly one meaning and one model. The insight is that most enterprise modelling arguments are people trying to build a single definition of 'order' or 'user' that satisfies four departments, which cannot be done. Drawing the boundary instead — and translating at the edges — is what lets each team's model stay simple, and it is usually the honest answer to a schema argument that has run for a week.
Full entry →