When an application loads an existing aggregate back from a database row or an event stream, why is this 'reconstitution' path usually kept separate from the factory method used to create a brand-new aggregate, even though both end up producing the same aggregate type?

## What a creation factory actually asks A creation factory answers the question **'is it valid for a brand-new instance of this aggregate to come into existence with these values right now?'** That question only makes sense at the moment of birth. An `Order` factory might refuse to create an order with status 'shipped,' because a shipped order implies a sequence of prior events - placed, paid, packed, shipped - that a synthetic freshly-created object skipped entirely. But when the application restarts, or a request comes in for order #4821, the system needs to load an order that is, quite legitimately, already in the 'shipped' state, because it went through that whole lifecycle over the preceding weeks. If the only path back into an `Order` object were the same `Order.create(...)` factory used for new orders, that factory would either: - reject a perfectly valid stored order (because its creation-time invariants forbid a starting status of 'shipped') - or need special-case flags to bypass those checks - at which point every caller of 'create' has to reason about which flags are safe, quietly eroding the very guarantee the factory exists to provide ## The second path in The mechanism, concretely: most systems add a second path into the aggregate, often called **reconstitution**, **rehydration**, or (in ORMs) simply **'hydration.'** This path takes data already known to represent a once-valid, and presumably still-valid, aggregate state - a row fetched from the aggregate's own table(s), or the output of replaying a stream of domain events for an event-sourced aggregate - and assembles the aggregate object directly, without re-running the create-time business validation. It typically still goes through the aggregate's own controlled construction surface rather than a fully public constructor: - a package-private constructor - a static `reconstitute(...)` method - an ORM's ability to set private fields via reflection/bytecode manipulation The goal isn't 'anything goes' - it's 'trust the source of this data, but still assemble it through the type's real internal shape' so you don't end up with, say, a value object that skips its own construction-time normalization. ## Event sourcing makes the distinction sharpest Event-sourced aggregates make the distinction sharpest: reconstitution there isn't a database row mapping at all, it's replaying every domain event ever recorded for that aggregate's id, in order, applying each one to progressively rebuild current state (an `apply(OrderPlaced)`, `apply(OrderPaid)`, `apply(OrderShipped)` sequence). This is fundamentally not the same operation as creation, because creation-time factories in an event-sourced system typically just decide whether to emit the very first event (e.g., `OrderPlaced`) - they never see the full lifecycle at once, whereas reconstitution sees and replays the entire history to arrive at the current snapshot. ## The trade-off The trade-off of keeping these paths separate is a bit more code: - two distinct entry points into the aggregate to understand and maintain instead of one - a discipline requirement that any new construction-time invariant added to the 'create' factory be deliberately considered for whether reconstitution needs an equivalent (usually not, since reconstitution trusts already-validated data, but occasionally a defensive check is warranted if the store might have been corrupted or manually edited) The benefit is that 'create' stays strict and trustworthy - it's always safe to assume anything produced by the create factory is a legitimately new, rule-compliant instance - while reconstitution stays efficient and doesn't waste cycles re-validating rules on every single object load, which matters a lot at scale (loading an aggregate happens far more often than creating one). ## Failure modes Failure modes when this separation is missing or done carelessly are common in practice. 1. **Performance.** Teams that accidentally run full create-time validation (including things like external uniqueness checks against other aggregates) on every load slow down every read path unnecessarily. 2. **Data corruption tolerance.** Another failure mode: if reconstitution is implemented via raw reflection that bypasses the aggregate's constructor entirely (common with some ORMs, e.g., Hibernate's default no-arg constructor plus field injection), it's easy to end up with an aggregate whose invariants were never actually checked by anything, because both the create-time factory and the reconstitution path got skipped - a corrupted or manually-edited database row silently produces an aggregate object the domain model assumes is always valid. A well-known real-world pattern for exactly this is event-sourcing frameworks like Axon or EventStoreDB, which draw a hard architectural line between a command-handler-driven creation path that decides whether to emit a first event, and a separate event-replay/snapshot-loading path used purely to rebuild in-memory state - the two are never the same code path, by design.