The Factory
Knows Where to Put It

One codebase generates an Aggregate's identifier inside the Aggregate's own constructor — a plain UUID call, no dependency on anything outside the Domain layer. Another generates the identifier by calling out to a Repository method first, in the Application layer, then hands the already-generated ID into a Factory that builds the Aggregate. Same underlying operation — a UUID v4 with the hyphens stripped, nothing more exotic than that — done in two structurally different places. The natural question is which one is "correct" Domain-Driven Design. That question turns out to have a specific, citable answer, and it isn't the one either codebase's own convention implies.

The Two Answers, Side by Side

The constructor version reads like this — the Aggregate is complete and self-sufficient the moment it exists, ID included:

class Order {
  readonly orderId: string
  constructor(params: { orderId?: string; ... }) {
    this.orderId = params.orderId ?? generateId()
  }
}

The Factory version routes the same value through an extra hop — Application asks Infrastructure for an ID, then hands it to a Factory:

// application layer
const account = accountFactory.create({
  ...command,
  id: await accountRepository.newId(),
})

Both produce the exact same kind of value. Neither touches a database to do it — newId() turns out to be nothing more than uuid.v4() under the hood, wrapped in a Repository method for no reason the code itself explains. On the surface, the constructor version looks leaner, and it's tempting to read the Factory version as a codebase that simply hasn't caught up.

What the Book Actually Says

Eric Evans' Domain-Driven Design (2003) addresses this directly, in the chapter on Factories, under a section asking exactly this question — where does the responsibility for assigning identity belong:

"When the program is assigning an identifier, the Factory is a good place to control it. Although the actual generation of a unique tracking id is typically done by a database 'sequence' or other infrastructure mechanism, the Factory knows what to ask for and where to put it."

That is, close to verbatim, the second codebase's shape: a Factory that doesn't generate the identifier itself, but knows to ask an outside mechanism for one and knows where it goes once it arrives. The book doesn't describe the constructor-does-it-all version as the default at all — the Factory-mediated version is the one it actually walks through.

Why the Original Answer Pointed at Infrastructure

The reason becomes clear from the rest of the passage: in 2003, "the actual generation of a unique tracking id" meant, in the overwhelming majority of real systems, a database sequence — an auto-incrementing counter the database itself owned and handed out on request. There was no way to get that value without asking the database for it, which meant there was no way to write a self-sufficient constructor the way the first codebase's UUID version does. The Factory's job, as the book frames it, was specifically to hide that infrastructure round-trip from the rest of the domain model — the Factory "knows what to ask for," so nothing else has to.

What Changed the Calculus

A UUID doesn't have this problem. Generating one requires no coordination with anything external — no sequence to increment, no round trip, no shared counter to protect from collisions. The entire reason the book routes identity assignment through a Factory talking to an outside mechanism stops applying the moment the identifier no longer needs an outside mechanism at all. A constructor calling a UUID function directly isn't skipping a step DDD requires; it's a simplification that only became available once the identifier stopped depending on infrastructure to exist.

Neither Codebase Was Actually Wrong

The Factory-mediated codebase is doing precisely what the foundational text describes for program-assigned identity. The constructor-only codebase is doing something the text never explicitly rules out and that later became simpler to justify, once UUIDs made the infrastructure hop optional rather than required. What looked, at first glance, like one codebase following a rule and the other having drifted from it turns out to be neither — one inherited a pattern built for a constraint that no longer exists, and the other quietly stopped needing it.