Your team enforces a strict rule that each transaction may modify at most one aggregate. A new Order aggregate is created by reserving stock across several Product aggregates and then persisting the Order. How should the factory/creation logic be structured so it respects the one-aggregate-per-transaction rule while still guaranteeing the Order is never created with stock it can't actually claim?

## Why the rule and the factory pull against each other A one-aggregate-per-transaction rule exists to keep each transaction small, fast, and free of lock contention across unrelated aggregates - it's a deliberate constraint many DDD-influenced systems adopt specifically so that aggregates can scale independently and so that a transaction touching `Order` never blocks or gets blocked by a transaction touching an unrelated `Product`. The tension this creates for factories is direct: the textbook description of a factory **'guaranteeing invariants at construction time'** implicitly assumes the whole operation - checking and committing - happens as one atomic unit. Creating an `Order` that depends on successfully claiming stock from several different `Product` aggregates cannot be that: - doing it in one transaction means locking multiple aggregate rows together, exactly what the one-aggregate-per-transaction rule forbids - and even without that rule, at scale this creates severe lock contention on hot products ## The resolution: a short business process The resolution is to stop treating 'create the `Order`' as a single atomic operation and instead treat it as a short business process with its own intermediate states, sometimes implemented as a **saga** or **process manager**, sometimes as a simpler two-phase reserve/commit sequence. Concretely: 1. Each `Product` aggregate gets a `reserve(quantity)` command that, inside its own single-aggregate transaction, checks available stock and, if sufficient, creates a reservation record (a hold, not a permanent decrement) and returns a reservation id. 2. The orchestrating logic - which may live in an application service coordinating the process rather than inside any one aggregate's factory - calls `reserve` on each `Product` involved, one transaction at a time. 3. Only once all reservations succeed does it invoke the `Order` factory, in its own transaction, passing the collected reservation ids; the factory's job at that point is back to being purely local - validate that reservation ids are present and well-formed, compute the order total, assign an order number, and construct the aggregate. 4. If any individual reservation fails (stock actually insufficient, product deleted, etc.), a compensating step releases whatever reservations were already taken, and `Order` creation is aborted before the factory is ever called. ## What the guarantee narrows to This design still gives the `Order` factory a real invariant guarantee, but it's a guarantee about a narrower, purely local claim: an `Order` object returned by this factory always references reservation ids that were confirmed to exist. It does not, and structurally cannot, guarantee that the stock is still physically available right now, because time has passed since the reservations were taken and reservations themselves typically expire (a common pattern: a reservation is a hold valid for a fixed window, after which it's automatically released if not confirmed by a completed `Order` or payment). This is the DDD analogue of the local-vs-cross-aggregate invariant distinction taken to its logical multi-step conclusion: what used to be 'one factory call, one guarantee' becomes 'several local guarantees stitched together by a process that can fail partway and must know how to unwind.' ## The trade-off The trade-off is substantial added complexity. The team now needs to: - design and implement compensating actions (releasing reservations) - handle partial failure (three of four products reserved, the fourth is out of stock - now what happens to the three?) - decide on reservation expiry policy - often needs idempotency keys on the reserve operation so retries after a timeout don't double-reserve This is meaningfully harder to build and reason about than a single transactional factory call, and teams should only take it on when the one-aggregate-per-transaction constraint (or an equivalent distributed-systems reality, like the aggregates living in genuinely different services or databases) actually forces it - within a single database with no such rule, a pragmatic team might just wrap `Order` creation and `Product` stock decrements in one database transaction and accept the coupling, if the scale doesn't punish it. ## Failure modes in production Failure modes in production when this is built carelessly: - reservations that are taken but never released because the compensating action wasn't wired up for every failure path, silently locking stock that customers can't actually buy until an expiry job eventually cleans it up - race conditions between two orders both reserving the last unit of stock if the reserve operation itself isn't implemented with proper optimistic or pessimistic concurrency control inside the `Product` aggregate - orphaned Orders referencing reservation ids that later expired before payment completed, requiring an explicit recheck at a later step rather than assuming the Order's existence implies the stock is still held A well-known real-world pattern matching this shape is the **Saga pattern** as popularized in microservices architecture (and, in DDD circles, discussed extensively by Vaughn Vernon), where a long-running business process coordinates multiple aggregates - potentially across service boundaries - through a sequence of local transactions and compensating actions rather than a single distributed transaction, precisely because distributed two-phase commit across aggregate/service boundaries is avoided in favor of eventual consistency with explicit unwind logic.