ddd-factory

One-line summary

A factory encapsulates the knowledge needed to create a complete, valid aggregate or value object when construction itself is complex or has domain meaning.

When to use this skill

• Creation requires assembling multiple sub-objects (a new Order is born with line items, an initial status, a created-at timestamp).
• Creation must enforce invariants beyond simple field validation (a new Subscription must reference a valid Plan and a non-cancelled Customer).
• The act of creation has a domain-meaningful name in the ubiquitous language (Order.placeFor(customer, items), Account.openFor(applicant)) — not just new Order(...).

When NOT to use this skill

• Simple objects whose constructor fully captures the work.
• A static creation method on the entity itself is sufficient — promote to a separate factory class only when the creation logic doesn't belong on the resulting object, or when multiple aggregates collaborate during creation.
• The "factory" you are tempted to write would just call new — that is ceremony, not encapsulation.

Core content

Three common shapes, from least to most ceremony: