Factories (DDD)

## What an aggregate promises An **aggregate** in DDD is a cluster of entities and value objects treated as one consistency unit, guarded by a root entity that enforces the business rules (**invariants**) that must always hold for that cluster. One of the strongest guarantees a well-designed aggregate offers is that it can never be observed in an invalid state by anything outside it - not right after construction, not mid-update. That guarantee is easy to break at exactly the moment of creation, because creating a real aggregate often takes several dependent steps: - validating raw input - deriving fields from other fields - generating or reserving an identity - creating child value objects - wiring everything together in the right order A public no-op constructor that just assigns whatever it's handed puts all of that responsibility on every single call site. If ten different places in the codebase construct an `Order`, and only nine of them remember to also compute the tax line and set the initial status, the tenth becomes a silent time bomb - a supposedly valid aggregate that is actually broken, discovered only later when some downstream code trips over the missing field. ## How a factory closes the gap A factory exists to close that gap by becoming the one and only sanctioned path to a valid instance. Concretely this means: - the constructor itself becomes **private or package-private** (so it cannot be called from outside) - a **factory method or factory class** becomes the public entry point Callers pass in raw, possibly-untrusted input; the factory validates it, performs whatever computation or lookups are needed, and only then invokes the constructor with data it has already proven consistent. If validation fails, the factory refuses to produce an object at all - it throws, returns a Result/Either type, or otherwise signals failure - so there is no window in which an invalid aggregate escapes into the rest of the system. This is often summarized as **'make illegal states unrepresentable'**: by removing every other route to construction, the type system and the factory together guarantee that any `Order` object you can get your hands on is, by definition, one that passed its rules. ## The trade-off The trade-off is indirection and a small amount of ceremony. A trivial aggregate with one or two fields and no cross-field rules gains little from a factory - a public constructor with parameter validation inline is often perfectly fine, and DDD is explicit that factories are for complex creation, not a mandatory ritual for every object. Overusing factories on simple aggregates adds a layer developers must learn to navigate for no real safety benefit, and can obscure what should be a two-line constructor behind a static method and a builder-style call. The judgment call is proportional to complexity: does creation involve more than trivial field assignment - multiple related invariants, computed values, identity assignment, or coordination between two or more child entities? If yes, a factory earns its keep. ## Failure modes when this is skipped Failure modes when this is skipped in production tend to look the same regardless of language or framework: - aggregates that pass unit tests (because tests happen to call the constructor correctly) but produce corrupted data once real, messier input reaches a different call site - duplicate, slightly-divergent validation logic scattered across controllers, batch jobs, and test fixtures that each reinvent 'how do I build an Order' and drift out of sync over time - invariant violations that only surface downstream, e.g., a report job crashing on a null total because one code path forgot to set it Retrofitting a factory after the fact is also more painful than starting with one, since every existing call site that used the constructor directly has to be found and migrated, and any bad data already persisted has to be cleaned up or defended against. ## Where it shows up A concrete, widely-cited framing comes from Eric Evans's original DDD book, which treats a factory for assembling an Aggregate as being just as deliberate a design decision as choosing the aggregate boundary itself - the two are meant to be designed together, because the factory is what encodes 'how do you legally get one of these.' A practical real-world analogue is an e-commerce `Order` aggregate whose factory, all before the constructor is ever invoked: 1. computes line totals 2. applies applicable promotions 3. generates an order number from a sequence 4. sets the initial 'pending' status Callers just supply a cart and a customer and always receive a fully-formed, rule-compliant `Order`.