@archi-code/ddd 3.0.0-alpha.1 → 3.0.0-alpha.2

package/ddd-skills/archi-code-ddd/what-not-to-do.md

@@ -17,7 +17,9 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
   broker), so it must be a stable literal, unique per listener.
 - Subscribing listeners by a text name or calling them from a use case: the composition root
   subscribes them with `bus.subscribe(listener)`, which reads their `@ListensTo`.
-- Declaring `eventName()` as a method in an event: declare `static readonly eventName`.
+- Declaring `eventName` as a method or an instance field in an event, or adding methods to it:
+  declare `static readonly eventName`; the base copies it into the event's `eventName` field, and
+  an event is plain data.
 - Importing the repository contracts from `@archi-code/ddd/application`: they live in `/domain`.
 - Do not invent API: there is no root `@archi-code/ddd` import, no `toPrimitives()` in the base
   classes, no generic `ValueObject` (a value object of several fields is `Composite({...})`), no
@@ -38,7 +40,7 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
   (`new OrderPlaced(id.value, customer.value)`): `occurredOn` becomes the system time and tests stop
   being deterministic.
 - A registry factory that does not pass the JSON as metadata
-  (`(json) => new OrderShipped(json.aggregateId)`): the event gets a new `eventId`, a listener
+  (`(json) => new OrderShipped(json.orderId as string)`): the event gets a new `eventId`, a listener
   cannot skip a redelivery, and `fromJSON` throws.
 - Subscribing a listener of an event the `EventRegistry` does not know: `bus.subscribe` refuses it
   with `UnknownEventException`; register every event a listener receives.
@@ -54,8 +56,10 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 - A read query that loads aggregates through `AggregateFinder`, or a repository method that
   returns DTOs: reads go straight to the database through an application interface.
 - Importing `@archi-code/ddd/infrastructure` from domain code, or `application` from the domain.
-- Importing an exception from `@archi-code/ddd/domain`: exceptions live in
-  `@archi-code/ddd/exceptions`.
+- Importing an exception from another layer's subpath: each layer exports its own
+  (`ValidationException` from `/domain`, `AggregateNotFoundException` from `/application`,
+  `InternalErrorException` from `/infrastructure`); there is no `/exceptions` subpath and the
+  common base class is not exported (check the three layer bases, or use `ExceptionClassifier`).
 - Catching errors inside `handle` just to rethrow them as `ApplicationException`: let them
   propagate; `execute` keeps package exceptions and wraps the rest.
 - Calling `bus.publish` before `repository.save`, or publishing without `pullDomainEvents()`.
@@ -68,10 +72,10 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
   them with the aggregate in the same atomic write (an outbox) and a relay delivers them.
 - A listener that breaks when a channel delivers the same event twice: delivery is at least once;
   skip an `eventId` already processed.
-- Sending `event.toJSON()` of a domain event to another context: translate it to a published,
+- Sending a domain event as it is (`{ ...event }`) to another context: translate it to a published,
   versioned contract.
-- Changing the data of a stored or published event without raising `eventVersion` (or the
-  contract version).
+- Changing the data of a stored or published event incompatibly under the same `eventName` (or
+  the same contract version) when no factory can read both shapes: publish a new event instead.
 - Repository methods with business names or rules (`pendingOlderThan`, `findOverdueInvoices`),
   `nextId()` in a repository, or a use case returning the aggregate to the controller.
 - Throwing `AggregateNotFoundException` from the domain or a repository: the use case throws it when
@@ -102,7 +106,7 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 - Comparing VOs or entities with `===`: use `equals()`.
 - Calling `assertValid()`: it does not exist; the constructor already throws `ValidationException`.
 - Building the value objects of an input one after another with `new` in `toCommand`: the first
-  invalid field hides the rest. Use `ValueObjects.build` so every field is reported.
+  invalid field hides the rest. Use `ValueObjectBuilder.build` so every field is reported.
 - Moving a value object's rule to the request schema or the controller (`isEmail` in a DTO
   validator instead of the `Email` value object): the adapter may check format for the user
   (empty, length) [IDDD ch. 4], but the value object owns the rule and always checks it.
@@ -156,17 +160,20 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 - Converting an aggregate to or from primitives outside the aggregate (a domain service, a
   hand-written mapper reading its fields): the aggregate owns `toPrimitives()` and
   `static fromPrimitives()`.
-- Declaring a `version` field in an aggregate, or putting it in `toPrimitives()`: the base already
-  has it, and the repository stores it next to the primitives.
+- Declaring a `version` field in an aggregate, or putting it in `toPrimitives()`: the version is
+  the repository's, which keeps it in its own `WeakMap` and stores it next to the primitives.
 - A repository (also the in-memory one of the tests) that saves with `upsert` and no version
   condition, or "last save wins": a stale save must throw `ConcurrencyException`.
-- Forgetting `markPersisted()` after a successful write (the next save of the same object becomes a
-  false conflict), or `Order.fromPrimitives(row)` without `.restoreVersion(storedVersion)` (every load looks
-  new, and the first save conflicts).
-- Calling `restoreVersion()` or `markPersisted()` from domain or application code: they are for
-  repositories.
-- Creating events without the aggregate id (`super()`), or generating `eventId`/`occurredOn`
-  yourself for a new event: the base does it.
+- A repository that forgets to remember `version + 1` after a successful write (the next save of
+  the same object becomes a false conflict), or the stored version on load (every load looks new,
+  and the first save conflicts).
+- Exposing the version to domain or application code: use cases load, change and save; only the
+  repository knows it.
+- Creating events without the id of their aggregate as a payload field (`readonly orderId: string`),
+  or generating `eventId`/`occurredOn` yourself for a new event: the base does it.
+- Putting value objects, `Date`s, `undefined` or class instances in an event's fields (nothing
+  checks it at run time): each event declares only the primitive data it needs (`id.value`,
+  money as `{ amount, currency }`, `date.toISOString()`).
 - Wrapping or translating an error (`InternalErrorException`, `ConcurrencyException`,
   `NotAllowedException`, `AggregateNotFoundException`) without `{ cause: error }`.
 - `JsonType` with `{}` or with an array: throws `TypePrimitiveException` (it must be a non-empty
@@ -183,7 +190,7 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 - Logging from the domain, or importing a logging library (pino, winston, `console`) in a use case:
   inject the `Logger` port and choose the provider in the composition root.
 - Logging an error and rethrowing it in every layer: the edge that handles it logs it once
-  (`HttpErrorMapper` and `DomainEventBus` with a logger already do).
+  (`DomainEventBus` with a logger already does; an entry point logs an `Internal` failure).
 - Interpolating data into the message (`` `order ${id} failed` ``) or logging passwords, tokens or
   personal data that the entry does not need: keep a stable message and put only what is needed in
   the context.

package/ddd-skills/archi-code-ddd/where-each-class-goes.md

@@ -4,27 +4,27 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 
 | Class                                                        | Layer                                   | May depend on                                                                             | Never                                                                      |
 | ------------------------------------------------------------ | --------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
-| Value object, composite                                      | domain                                  | other value objects, `@archi-code/validation`, exceptions                                 | mutate, know about storage or transport                                    |
+| Value object, composite                                      | domain                                  | other value objects, `@archi-code/validation`, domain exceptions                          | mutate, know about storage or transport                                    |
 | Aggregate root (`extends AggregateRoot`)                     | domain                                  | value objects, child entities, events; a domain service or loaded data as method argument | read a repository, publish, `new Date()`, services received by constructor |
 | Child entity (`extends Entity`)                              | domain                                  | its local id, value objects, business methods the root calls                              | setters, being called from outside the root, loaded or saved on its own    |
 | Domain event (`OrderPlaced`)                                 | domain                                  | primitives taken from value objects                                                       | behavior, value objects or the whole state in its payload                  |
 | Repository contract (`AggregateFinder`…)                     | domain                                  | the aggregate                                                                             | business logic or queries, an all-in-one `Repository`                      |
 | Domain service                                               | domain                                  | aggregates, value objects, specifications, repository contracts (to read), domain ports   | I/O code, transactions, publishing                                         |
 | Domain port to another context or service (`ProductPricing`) | domain                                  | value objects                                                                             | remote DTOs, I/O code                                                      |
-| Use case (`PlaceOrder`)                                      | application                             | domain, ports, exceptions                                                                 | import another use case or a listener, return an aggregate                 |
+| Use case (`PlaceOrder`)                                      | application                             | domain, ports and exceptions                                                              | import another use case or a listener, return an aggregate                 |
 | Listener (`ReserveStockOnOrderPlaced`)                       | application                             | one use case (by constructor), the event                                                  | business rules, saving aggregates, calling several use cases               |
 | Port (`EventBus`, `Clock`, `Logger`, your own) | application                             | domain types                                                                              | code                                                                       |
 | Read query (`OrderSummaries`, `StaleOrders`)                 | application (interface), infrastructure | DTOs and ids, `@archi-code/criteria`                                                      | loading aggregates, repositories, business rules                           |
 | Adapter (repository, event channel, ACL translator, logger provider) | infrastructure                          | domain, application, exceptions, drivers                                                  | business rules                                                             |
 | Event wiring (`DomainEventBus`, `EventRegistry`, `EventChannel` port and its implementations) | infrastructure (composition root) | `@archi-code/ddd/infrastructure`, domain events, listeners                     | being seen by use cases (they only see `EventBus`) or listeners             |
-| Entry point (controller, consumer, scheduler, CLI)           | interfaces                              | application, exceptions, `HttpErrorMapper`; domain types only if unavoidable              | business rules, repositories or other adapters                             |
+| Entry point (controller, consumer, scheduler, CLI)           | interfaces                              | application, `ExceptionClassifier` and `ExceptionKind`; domain types only if unavoidable  | business rules, repositories or other adapters                             |
 | Composition root (`composition.ts`)                          | per context                             | everything                                                                                | being imported by any layer                                                |
 
-- Dependencies only point inwards: the domain imports only `@archi-code/ddd/domain`,
-  `@archi-code/ddd/exceptions` and `@archi-code/validation` (not "nothing external" as the suite
-  says: these are the package convention); the application adds `@archi-code/ddd/application`;
-  only infrastructure and the composition root import `@archi-code/ddd/infrastructure`, with one
-  exception: an entry point may import `HttpErrorMapper` (or receive it from the composition root).
+- Dependencies only point inwards: the domain imports only `@archi-code/ddd/domain` and
+  `@archi-code/validation` (not "nothing external" as the suite says: these are the package
+  convention); the application adds `@archi-code/ddd/application`; only infrastructure and the
+  composition root import `@archi-code/ddd/infrastructure`, except that an entry point imports
+  `ExceptionClassifier` and `ExceptionKind` from it to translate errors (they hold no adapter).
   Entry points (`interfaces/`: controllers, message consumers, schedulers, CLI) call use cases
   only. The composition root of each context is the only place that builds and connects everything
   (repositories, event channel, `DomainEventBus`, `EventRegistry`, listeners) and reads
@@ -53,8 +53,9 @@ Part of the `archi-code-ddd` skill: read it only when that skill routes here.
 - Check the direction with dependency-cruiser (`tsPreCompilationDeps: true`) and the suite's
   `ddd-skills/ddd-arquitectura/assets/dependency-cruiser.cjs`, which already allows the `@archi-code/ddd`
   layers above and forbids importing `composition.ts`.
-- Import from the layer, never from the package root (there is none): exceptions always come from
-  `@archi-code/ddd/exceptions` (never from `/domain`).
+- Import from the layer, never from the package root (there is none): each exception comes from
+  the subpath of its layer (`DomainException` from `/domain`, `AggregateNotFoundException` from
+  `/application`, `InternalErrorException` from `/infrastructure`); there is no `/exceptions`.
 - Logic two use cases share never goes in a use case: a business rule becomes a method of the
   aggregate or a domain service; a technical step becomes a port. When an action must follow
   another, the first records an event and a listener runs the second.

package/ddd-skills/ddd-agregados/GUIA.md

@@ -8,7 +8,7 @@
 
 [Fuera de los libros: convención de @archi-code/ddd]
 
-* La raíz no se escribe: extiende `AggregateRoot<Id, Event>` y llama a `super(id)`; la `version` de la concurrencia optimista está en la base, fuera del estado del agregado, y solo la tocan los repositorios (`restoreVersion()` al cargar, `markPersisted()` tras escribir).
+* La raíz no se escribe: extiende `AggregateRoot<Id, Event>` y llama a `super(id)`; el agregado no declara ni mapea ninguna `version`: la de la concurrencia optimista es solo del repositorio, que recuerda la de cada agregado cargado o guardado en un `WeakMap<Order, number>` y la actualiza solo tras escribir con éxito; el caso de uso nunca la ve.
 * Todo el estado son value objects, composites o entidades hijas con getter público; constructor privado, una factoría de negocio y `fromPrimitives`, y `toPrimitives()` con datos planos (las seis reglas de `layers.md`).
 * Las identidades nuevas salen del value object (`OrderId.generate()`), no del repositorio.
 * Los métodos del dominio reciben `clock: { now(): Date }` y lo pasan a los eventos (`{ clock }`).
@@ -68,7 +68,7 @@ Guía completa en `ddd-skills/ddd-agregados/references/implementacion-ts.md`. Lo
 * Partes internas como **value objects** siempre que se puedan reemplazar enteras [IDDD cap. 10].
 * Comportamiento con nombres del lenguaje; sin setters públicos. Ley de Demeter y "Tell, Don't Ask": los clientes piden a la raíz que haga algo, no navegan por dentro [IDDD cap. 10].
 * **No inyectes repositorios ni servicios en el agregado.** Busca antes lo que necesite (en el servicio de aplicación) y pásaselo al método [IDDD cap. 10].
-* **Concurrencia optimista** con versión en la raíz [IDDD cap. 10]: la `version` de `AggregateRoot`, que el repositorio comprueba al guardar (`ConcurrencyException`).
+* **Concurrencia optimista** con versión en la raíz [IDDD cap. 10]: con el paquete la guarda el repositorio (un `WeakMap` con la versión de cada agregado que cargó o guardó, almacenada junto a los primitivos, nunca dentro) y la comprueba al guardar y al borrar (`ConcurrencyException`) `[Fuera de los libros: convención de @archi-code/ddd]`.
 * El agregado **registra** sus eventos (`record`); el caso de uso los publica tras guardar con `events.publish(order.pullDomainEvents())` (ver `ddd-skills/ddd-eventos-dominio/GUIA.md`).
 * **Distingue comandos de hechos.** Un comando de usuario puede rechazarse con un error de negocio. Un método que registra un hecho ya ocurrido en otro agregado o contexto es idempotente y no lanza: si el hecho no encaja, registra un evento de negocio para que otra política compense [Destilado cap. 6]. Una excepción en un consumidor de mensajes provoca reintentos sin fin.
 * Creación con **fábricas**: método en la raíz de otro agregado cuando el nuevo nace de él (`customer.placeOrder(...)`), o servicio cuando la creación necesita traducir de otro contexto [IDDD cap. 11; PHP: Factories]. Ver `ddd-skills/ddd-agregados/references/fabricas.md`.

package/ddd-skills/ddd-agregados/references/consistencia-eventual.md

@@ -32,12 +32,12 @@ export class StockReserved extends EventBase {
   static readonly eventName = 'warehouse.stock.StockReserved';
 
   constructor(
-    stockItemId: string,
+    readonly stockItemId: string,
     readonly orderId: string,
     readonly reservationId: string,
     metadata?: EventMetadata,
   ) {
-    super(stockItemId, metadata);
+    super(metadata);
   }
 }
 ```
@@ -45,9 +45,8 @@ export class StockReserved extends EventBase {
 El caso de uso registra el hecho: un agregado, un `save` atómico, y si el pedido no existe (es de otro canal) vuelve sin error:
 
 ```ts
-import { ValueObjects } from '@archi-code/ddd/domain';
 import type { AggregateFinder, AggregateSaver } from '@archi-code/ddd/domain';
-import { UseCase } from '@archi-code/ddd/application';
+import { UseCase, ValueObjectBuilder } from '@archi-code/ddd/application';
 import type { Clock, EventBus } from '@archi-code/ddd/application';
 
 interface StockReservationInput {
@@ -74,7 +73,7 @@ export class RegisterStockReservation extends UseCase<
   }
 
   protected toCommand(input: StockReservationInput): StockReservationCommand {
-    return ValueObjects.build({
+    return ValueObjectBuilder.build({
       orderId: () => new OrderId(input.orderId),
       reservationId: () => new ReservationId(input.reservationId),
     });
@@ -127,7 +126,7 @@ const orders = new InMemoryOrderRepository();
 const registry = new EventRegistry<OrderEvent | StockReserved>().register(
   StockReserved,
   (json) =>
-    new StockReserved(json.aggregateId, json.orderId as string, json.reservationId as string, json),
+    new StockReserved(json.stockItemId as string, json.orderId as string, json.reservationId as string, json),
 );
 const channel = new InMemoryEventChannel();
 const bus = new DomainEventBus<OrderEvent | StockReserved>(channel, registry);

package/ddd-skills/ddd-agregados/references/fabricas.md

@@ -15,9 +15,8 @@ No contradice la regla de una transacción por agregado: el creador no se modifi
 `Order`, `OrderId`, `OrderLines` y `ShippingAddress` son los de `references/implementacion-ts.md`:
 
 ```ts
-import { AggregateRoot, BooleanType, Required, StringType } from '@archi-code/ddd/domain';
+import { AggregateRoot, BooleanType, DomainException, Required, StringType } from '@archi-code/ddd/domain';
 import type { PrimitiveTypes } from '@archi-code/ddd/domain';
-import { DomainException } from '@archi-code/ddd/exceptions';
 import { Validations } from '@archi-code/validation';
 
 export class CustomerName extends Required(StringType) {}
@@ -86,11 +85,9 @@ export class Customer extends AggregateRoot<CustomerId> {
 La regla de creación ("un cliente bloqueado no puede realizar pedidos") vive en `Customer`. El caso de uso lee el cliente con `AggregateFinder<Customer>`, genera la identidad nueva con `OrderId.generate()` y guarda solo el pedido con `AggregateSaver<Order>`; `Customer` no se guarda porque no ha cambiado:
 
 ```ts
-import { ValueObjects } from '@archi-code/ddd/domain';
 import type { AggregateFinder, AggregateSaver } from '@archi-code/ddd/domain';
-import { UseCase } from '@archi-code/ddd/application';
+import { AggregateNotFoundException, UseCase, ValueObjectBuilder } from '@archi-code/ddd/application';
 import type { Clock, EventBus } from '@archi-code/ddd/application';
-import { AggregateNotFoundException } from '@archi-code/ddd/exceptions';
 
 interface PlaceOrderInput {
   customerId: string;
@@ -115,7 +112,7 @@ export class PlaceOrder extends UseCase<PlaceOrderInput, PlaceOrderCommand, stri
   }
 
   protected toCommand(input: PlaceOrderInput): PlaceOrderCommand {
-    return ValueObjects.build({
+    return ValueObjectBuilder.build({
       customerId: () => new CustomerId(input.customerId),
       lines: () => OrderLines.fromPrimitives({ items: input.lines }),
       shippingAddress: () => ShippingAddress.fromPrimitives(input.shippingAddress),
@@ -173,7 +170,7 @@ describe('Customer.placeOrder', () => {
     );
     const order = customer.placeOrder(OrderId.generate(), lines, address, clock);
     expect(order.customerId.equals(customer.id)).toBe(true);
-    expect(order.pullDomainEvents().map((event) => event.eventName())).toEqual(['OrderPlaced']);
+    expect(order.pullDomainEvents().map((event) => event.eventName)).toEqual(['OrderPlaced']);
   });
 
   it('refuses an order from a blocked customer', () => {
@@ -192,5 +189,5 @@ describe('Customer.placeOrder', () => {
 
 ## Cuándo no
 
-* Para reconstituir desde base de datos: eso es `static fromPrimitives(primitives)`, que el repositorio llama directamente (`Order.fromPrimitives(row).restoreVersion(row.version)`), sin reglas de creación ni eventos.
+* Para reconstituir desde base de datos: eso es `static fromPrimitives(primitives)`, que el repositorio llama directamente (`Order.fromPrimitives(row.primitives)`; la versión de la fila la recuerda el repositorio en su `WeakMap`, no el agregado), sin reglas de creación ni eventos.
 * "Fábricas" genéricas que reciben un DTO y rellenan campos: un constructor con setters disfrazado.

package/ddd-skills/ddd-agregados/references/implementacion-ts.md

@@ -4,7 +4,7 @@ Contenido: 1. Raíz base · 2. Construcción paso a paso · 3. Agregado completo
 
 ## 1. Raíz base
 
-La raíz no se escribe a mano: se extiende `AggregateRoot<Id, Event>` de `@archi-code/ddd/domain`, que ya trae lo que IDDD cap. 10 describe para la raíz (identidad, igualdad por identidad, versión para la concurrencia optimista y lista de eventos registrados) `[Fuera de los libros: convención de @archi-code/ddd]`.
+La raíz no se escribe a mano: se extiende `AggregateRoot<Id, Event>` de `@archi-code/ddd/domain`, que ya trae lo que IDDD cap. 10 describe para la raíz salvo la versión (identidad, igualdad por identidad y lista de eventos registrados); la versión para la concurrencia optimista la guarda el repositorio, no el agregado (sección 5) `[Fuera de los libros: convención de @archi-code/ddd]`.
 
 ```ts
 import { AggregateRoot } from '@archi-code/ddd/domain';
@@ -24,10 +24,7 @@ La clase completa está en la sección 3. Lo que da la base:
 * `readonly id` y `equals(other)` (misma clase y mismo id) de `Entity<Id>`; un id sin valor lanza `RequiredValueException`.
 * `protected record(event)`: guarda el evento congelado (los hechos no cambian [IDDD cap. 8]).
 * `pullDomainEvents()`: devuelve los eventos en orden (tipados como `Event[]`) y vacía la lista; lo llama el caso de uso tras guardar.
-* `version`: `0` si es nuevo; no es un campo del agregado ni aparece en `PrimitiveTypes`.
-* `restoreVersion(v)` y `markPersisted()`: solo para repositorios (al cargar y tras escribir).
-
-Sin `markPersisted`, el objeto en memoria conservaría la versión antigua tras guardar y un segundo `save` del mismo objeto (por ejemplo, dos comandos seguidos en el mismo proceso) daría un falso conflicto de concurrencia `[Fuera de los libros]`. Los repositorios que sigan el contrato lo llaman siempre, también el `InMemoryOrderRepository` que el proyecto escribe en `test/support/` para los tests.
+La base no trae versión: el agregado no la declara, no la mapea en `toPrimitives()` y el caso de uso nunca la ve. Cada repositorio recuerda la versión de cada agregado que cargó o guardó en un `WeakMap<Order, number>` propio y la actualiza solo cuando la escritura ha ido bien; así un segundo `save` del mismo objeto (por ejemplo, dos comandos seguidos en el mismo proceso) no da un falso conflicto de concurrencia `[Fuera de los libros: convención de @archi-code/ddd]`. Lo cumplen todos los repositorios, también el `InMemoryOrderRepository` que el proyecto escribe en `test/support/` para los tests.
 
 Por qué registrar en vez de publicar: IDDD publica desde el agregado con un publicador estático [IDDD cap. 8]. Registrar y dejar que la aplicación publique no requiere un singleton global en el dominio y, con una bandeja de salida (outbox), evita entregar eventos de cambios que no llegaron a guardarse. *DDD in PHP* discute ambas variantes [PHP: Domain Events]. Con el paquete, el caso de uso llama a `await this.orders.save(order)` y después a `events.publish(order.pullDomainEvents())`; la aplicación no abre transacciones, porque la transacción es del repositorio. Si `publish` falla tras `save`, el evento puede perderse; cuando eso no es admisible, el repositorio guarda el agregado y sus eventos pendientes en la misma escritura atómica (outbox) y un proceso aparte los entrega por un `EventChannel`, y el caso de uso no cambia `[Fuera de los libros: convención de @archi-code/ddd]`.
 
@@ -55,7 +52,7 @@ import {
   Required,
   StringType,
 } from '@archi-code/ddd/domain';
-import { DomainException } from '@archi-code/ddd/exceptions';
+import { DomainException } from '@archi-code/ddd/domain';
 import { Validations } from '@archi-code/validation';
 
 export class OrderId extends IdType<'OrderId'> {}
@@ -191,9 +188,8 @@ export class OrderStatus extends Required(StatusType) {
 Eventos (hechos en pasado, con primitivos tomados de los value objects) y errores de negocio:
 
 ```ts
-import { EventBase } from '@archi-code/ddd/domain';
+import { DomainException, EventBase } from '@archi-code/ddd/domain';
 import type { EventMetadata } from '@archi-code/ddd/domain';
-import { DomainException } from '@archi-code/ddd/exceptions';
 
 export interface MoneyData {
   readonly amount: number;
@@ -210,13 +206,13 @@ export class OrderPlaced extends EventBase {
   static readonly eventName = 'OrderPlaced';
 
   constructor(
-    orderId: string,
+    readonly orderId: string,
     readonly customerId: string,
     readonly lines: readonly OrderLineData[],
     readonly total: MoneyData,
     metadata?: EventMetadata,
   ) {
-    super(orderId, metadata);
+    super(metadata);
   }
 }
 
@@ -224,14 +220,14 @@ export class OrderLineAdded extends EventBase {
   static readonly eventName = 'OrderLineAdded';
 
   constructor(
-    orderId: string,
+    readonly orderId: string,
     readonly sku: string,
     readonly quantity: number,
     readonly unitPrice: MoneyData,
     readonly total: MoneyData,
     metadata?: EventMetadata,
   ) {
-    super(orderId, metadata);
+    super(metadata);
   }
 }
 
@@ -239,11 +235,11 @@ export class OrderConfirmed extends EventBase {
   static readonly eventName = 'OrderConfirmed';
 
   constructor(
-    orderId: string,
+    readonly orderId: string,
     readonly total: MoneyData,
     metadata?: EventMetadata,
   ) {
-    super(orderId, metadata);
+    super(metadata);
   }
 }
 
@@ -251,13 +247,13 @@ export class OrderCancelled extends EventBase {
   static readonly eventName = 'OrderCancelled';
 
   constructor(
-    orderId: string,
+    readonly orderId: string,
     readonly reason: string,
     readonly reservationId: string | null,
     readonly paymentId: string | null,
     metadata?: EventMetadata,
   ) {
-    super(orderId, metadata);
+    super(metadata);
   }
 }
 
@@ -265,13 +261,13 @@ export class PaymentAuthorizationInsufficient extends EventBase {
   static readonly eventName = 'PaymentAuthorizationInsufficient';
 
   constructor(
-    orderId: string,
+    readonly orderId: string,
     readonly paymentId: string,
     readonly authorized: MoneyData,
     readonly required: MoneyData,
     metadata?: EventMetadata,
   ) {
-    super(orderId, metadata);
+    super(metadata);
   }
 }
 
@@ -474,7 +470,7 @@ Cómo encaja con las reglas:
 
 * `customerId` es una referencia por identidad (regla 3); `stockReservation` es la identidad de otro agregado de otro contexto, y `paymentAuthorization` un value object con lo mínimo que el pedido necesita de Pagos.
 * Las líneas son un value object (`OrderLines`, parte reemplazable entera); `addLine` sustituye la colección por la que devuelve `withLine`, y la regla de SKU único la comprueba el propio value object.
-* Constructor privado, una factoría de negocio (`place`, que registra `OrderPlaced`) y `fromPrimitives`, que reconstruye sin reglas de creación ni eventos; `toPrimitives()` devuelve solo datos planos. La conversión es solo del propio agregado (instantánea): el repositorio, cuyo constructor recibe solo las dependencias de su tecnología, llama directamente a `order.toPrimitives()` al escribir y a `Order.fromPrimitives(row).restoreVersion(row.version)` al leer, sin mapper ni comprobación de forma en medio, y no lee los campos. Quien añade un campo lo añade a `toPrimitives`/`fromPrimitives`, y el spec del agregado comprueba la ida y vuelta `[Fuera de los libros: convención de @archi-code/ddd]`.
+* Constructor privado, una factoría de negocio (`place`, que registra `OrderPlaced`) y `fromPrimitives`, que reconstruye sin reglas de creación ni eventos; `toPrimitives()` devuelve solo datos planos. La conversión es solo del propio agregado (instantánea): el repositorio, cuyo constructor recibe solo las dependencias de su tecnología, llama directamente a `order.toPrimitives()` al escribir y a `Order.fromPrimitives(row.primitives)` al leer (la versión de la fila la guarda en su `WeakMap`, no en el agregado), sin mapper ni comprobación de forma en medio, y no lee los campos. Quien añade un campo lo añade a `toPrimitives`/`fromPrimitives`, y el spec del agregado comprueba la ida y vuelta `[Fuera de los libros: convención de @archi-code/ddd]`.
 * Cada método recibe el reloj (`clock: { now(): Date }`) y lo pasa a los eventos (`{ clock }`): el dominio no llama a `new Date()` y los tests son deterministas.
 
 ### Comandos frente a hechos
@@ -483,7 +479,7 @@ Cómo encaja con las reglas:
 
 * Los métodos que reaccionan a hechos son **idempotentes** y **no lanzan errores de negocio**.
 * Si el hecho no encaja con las reglas, el agregado registra un evento con nombre del negocio (`PaymentAuthorizationInsufficient`) y otra política decide la compensación (anular la autorización, avisar al cliente). Así el problema queda visible en el modelo en vez de perdido en una cola de errores.
-* Los errores de negocio con excepción (`DomainException` con su código) quedan para comandos de usuario (`cancel`, `addLine`), donde alguien puede recibir la respuesta (`HttpErrorMapper` los traduce a 422 salvo que se le indique otro estado para su código).
+* Los errores de negocio con excepción (`DomainException` con su código) quedan para comandos de usuario (`cancel`, `addLine`), donde alguien puede recibir la respuesta (`ExceptionClassifier.classify(error)` los clasifica como `ExceptionKind.Invalid`, 422 en HTTP, y el punto de entrada puede dar otro estado a su código).
 
 Qué protege este agregado (sus invariantes, regla 1):
 * El total es siempre la suma de sus líneas (las líneas son un value object con su regla).
@@ -499,9 +495,8 @@ No inyectes repositorios ni servicios en el agregado. Busca antes lo necesario y
 El caso de uso construye los valores en `toCommand` y se los pasa al agregado en `handle`:
 
 ```ts
-import { ValueObjects } from '@archi-code/ddd/domain';
 import type { AggregateFinder, AggregateSaver } from '@archi-code/ddd/domain';
-import { UseCase } from '@archi-code/ddd/application';
+import { UseCase, ValueObjectBuilder } from '@archi-code/ddd/application';
 import type { Clock, EventBus } from '@archi-code/ddd/application';
 
 interface PaymentAuthorizationInput {
@@ -531,7 +526,7 @@ export class RegisterPaymentAuthorization extends UseCase<
   }
 
   protected toCommand(input: PaymentAuthorizationInput): PaymentAuthorizationCommand {
-    return ValueObjects.build({
+    return ValueObjectBuilder.build({
       orderId: () => new OrderId(input.orderId),
       authorization: () =>
         PaymentAuthorization.fromPrimitives({
@@ -560,7 +555,7 @@ El agregado recibe valores, no repositorios. Como registra un hecho (lo ejecuta
 
 ## 5. Concurrencia optimista
 
-* Versión en la raíz, incrementada con cada comando que cambie estado en cualquier parte del agregado [IDDD cap. 10]. Con el paquete es la `version` de `AggregateRoot`: el agregado no la declara ni la mapea, y solo la tocan los repositorios (`restoreVersion` al cargar, `markPersisted` tras escribir) `[Fuera de los libros: convención de @archi-code/ddd]`.
+* Versión en la raíz, incrementada con cada comando que cambie estado en cualquier parte del agregado [IDDD cap. 10]. Con el paquete la versión es solo del repositorio: el agregado no la declara ni la mapea y el caso de uso nunca la ve. El repositorio recuerda la versión de cada agregado que cargó o guardó en un `WeakMap<Order, number>` (`0` si no la conoce: es nuevo), escribe solo donde la versión guardada es esa, guarda `version + 1` junto a los primitivos (nunca dentro) y actualiza el `WeakMap` solo cuando la escritura ha ido bien (en SQL, tras el `COMMIT`) `[Fuera de los libros: convención de @archi-code/ddd]`.
 * Si las partes internas son entidades y el ORM no detecta su cambio como cambio de la raíz, es una señal más para reducir el agregado a raíz más value objects [IDDD cap. 10].
 * En almacenes de documentos o clave-valor el agregado se guarda entero y la versión se comprueba en una sola operación [IDDD cap. 10].
 
@@ -572,7 +567,7 @@ UPDATE orders
  WHERE id = $1 AND version = $4;
 ```
 
-Si la sentencia no afecta a ninguna fila, el repositorio lanza `new ConcurrencyException('Order', order.id.value, order.version)` (de `@archi-code/ddd/exceptions`, HTTP 409 con `HttpErrorMapper`; el nombre del agregado va como texto literal porque los minificadores renombran las clases); si escribe, llama a `order.markPersisted()`. En los tests lo cumple el `InMemoryOrderRepository` que el proyecto escribe en `test/support/`; el repositorio real y su suite de contrato están en `ddd-repositorios-persistencia`.
+`$4` es la versión que el repositorio recordaba (`this.versions.get(order) ?? 0`). Si la sentencia no afecta a ninguna fila, el repositorio lanza `new ConcurrencyException('Order', order.id.value, version)` (de `@archi-code/ddd/application`; `ExceptionKind.Conflict`, 409 en HTTP; el nombre del agregado va como texto literal porque los minificadores renombran las clases); un agregado nuevo (versión `0`) se inserta y un id que ya existe es también un conflicto. Si escribe, hace `this.versions.set(order, version + 1)`. En los tests lo cumple el `InMemoryOrderRepository` que el proyecto escribe en `test/support/`; el repositorio real y su suite de contrato están en `ddd-repositorios-persistencia`.
 
 Reintentar automáticamente solo es seguro si el comando es idempotente o se vuelve a evaluar contra el estado recargado: con el paquete, un bucle con límite en `handle` en el que cada intento vuelve a cargar el agregado y vuelve a guardarlo (unos pocos intentos y después se relanza); un caso de uso que ejecuta un listener no reintenta por su cuenta, lo hace la reentrega del canal `[Fuera de los libros: convención de @archi-code/ddd]`. Ejemplo en `ddd-skills/ddd-repositorios-persistencia/references/transacciones-ts.md`.
 
@@ -673,7 +668,7 @@ describe('Order', () => {
     expect(order.isConfirmed()).toBe(false);
     order.registerStockReservation(aReservation(), clock);
     expect(order.isConfirmed()).toBe(true);
-    expect(order.pullDomainEvents().map((event) => event.eventName())).toContain('OrderConfirmed');
+    expect(order.pullDomainEvents().map((event) => event.eventName)).toContain('OrderConfirmed');
   });
 
   it('records an insufficient authorization without throwing and without confirming', () => {
@@ -681,7 +676,7 @@ describe('Order', () => {
     order.registerStockReservation(aReservation(), clock);
     order.registerPaymentAuthorization(anAuthorizationOf(1000), clock);
     expect(order.isConfirmed()).toBe(false);
-    expect(order.pullDomainEvents().map((event) => event.eventName())).toContain(
+    expect(order.pullDomainEvents().map((event) => event.eventName)).toContain(
       'PaymentAuthorizationInsufficient',
     );
   });

package/ddd-skills/ddd-arquitectura/GUIA.md

@@ -8,7 +8,7 @@
 
 [Fuera de los libros: convención de @archi-code/ddd]
 
-* El dominio importa `@archi-code/ddd/domain`, `@archi-code/ddd/exceptions` y `@archi-code/validation` (no "nada externo"); la aplicación añade `@archi-code/ddd/application`; solo infraestructura y el composition root importan `@archi-code/ddd/infrastructure`, salvo `HttpErrorMapper` en los puntos de entrada.
+* Cada subpath del paquete exporta las excepciones de su capa y cada capa importa solo el suyo y los interiores: el dominio importa `@archi-code/ddd/domain` (con `DomainException`, `ValidationException`…) y `@archi-code/validation` (no "nada externo"); la aplicación añade `@archi-code/ddd/application` (con `AggregateNotFoundException`, `ConcurrencyException`, `NotAllowedException`…); solo infraestructura y el composition root usan `@archi-code/ddd/infrastructure` (con `InternalErrorException`), salvo los puntos de entrada, que traducen los errores con `ExceptionClassifier` de `@archi-code/ddd/infrastructure`.
 * No se escriben clases base ni puertos genéricos en el proyecto: `AggregateRoot`, `Entity`, `EventBase`, los tipos de value object y `Composite` vienen de `@archi-code/ddd/domain`; los contratos de repositorio son los roles `AggregateFinder`, `AggregateSaver` y `AggregateRemover` de `@archi-code/ddd/domain` (no hay un `OrderRepository` propio); `EventBus` y `Clock` vienen de `@archi-code/ddd/application` y `EventChannel` de `@archi-code/ddd/infrastructure`. No hay puerto de transacciones: el repositorio es responsable de la transacción y de todo lo relacionado con la persistencia.
 * Un mecanismo de mensajería es solo un `EventChannel` en `infrastructure/messaging/`; el bus es siempre `DomainEventBus`, y cambiar de tecnología cambia una línea del composition root. `DomainEventBus`, `EventRegistry` y el puerto `EventChannel` (con `ChannelHandler` y `ChannelSubscription`) se importan de `@archi-code/ddd/infrastructure`: son cableado de infraestructura. La aplicación solo ve el contrato para publicar (`EventBus`) y para escuchar (`EventListener` + `@ListensTo`) de `@archi-code/ddd/application`.
 * El composition root de cada contexto es el único que construye y conecta todo (repositorios, canal, `DomainEventBus`, suscripción de listeners con `bus.subscribe`) y lee `process.env`; nadie lo importa. El `dependency-cruiser.cjs` de esta guía ya aplica estas reglas.
@@ -37,10 +37,10 @@ infrastructure (adaptadores salida) ─┘                     ▲
 
 | Zona | Contiene | Puede depender de | Nunca |
 |---|---|---|---|
-| `domain` | Agregados (`AggregateRoot`), entidades (`Entity`), value objects, eventos de dominio (`EventBase`), servicios de dominio, puertos hacia servicios externos (`ProductPricing`); los contratos de repositorio son los roles `AggregateFinder`/`AggregateSaver`/`AggregateRemover` del paquete | Nada externo salvo `@archi-code/ddd/domain`, `@archi-code/ddd/exceptions` y `@archi-code/validation` | Framework web, ORM, cliente HTTP, `process.env`, logger |
+| `domain` | Agregados (`AggregateRoot`), entidades (`Entity`), value objects, eventos de dominio (`EventBase`), servicios de dominio, puertos hacia servicios externos (`ProductPricing`); los contratos de repositorio son los roles `AggregateFinder`/`AggregateSaver`/`AggregateRemover` del paquete | Nada externo salvo `@archi-code/ddd/domain` (también sus excepciones) y `@archi-code/validation` | Framework web, ORM, cliente HTTP, `process.env`, logger |
 | `application` | Casos de uso (`UseCase`), listeners (`EventListener` + `@ListensTo`), consultas de lectura con sus DTOs, puertos de salida no de dominio (`EventBus` y `Clock` del paquete; los tuyos, como `Warehouse`) | `domain`, `@archi-code/ddd/application` | Express/Fastify, SQL, detalles de mensajería |
 | `infrastructure` | Repositorios concretos (`MongoOrderRepository`), ACL, canales de eventos (`EventChannel`) y el cableado de eventos (`DomainEventBus`, `EventRegistry`, en el composition root), clientes HTTP; el repositorio se encarga de la atomicidad de cada escritura, la versión, la conexión y los errores del driver | `domain`, `application`, `@archi-code/ddd/infrastructure` | Lógica de negocio |
-| `interfaces` | Controladores REST, consumidores de mensajes, CLI, resolvers GraphQL | `application`, `HttpErrorMapper` (y tipos de `domain` solo si es imprescindible) | Lógica de negocio, acceso directo a repositorios |
+| `interfaces` | Controladores REST, consumidores de mensajes, CLI, resolvers GraphQL | `application`, las excepciones de `@archi-code/ddd/domain` y `/application`, `ExceptionClassifier` de `@archi-code/ddd/infrastructure` (y tipos de `domain` solo si es imprescindible) | Lógica de negocio, acceso directo a repositorios |
 
 Responsabilidades de los servicios de aplicación según IDDD: sin lógica de dominio, controlan transacciones y seguridad (en el paquete, la seguridad con `NotAllowedException`; la transacción pasa al adaptador del repositorio, que hace atómico cada `save` y `remove` `[Fuera de los libros: convención de @archi-code/ddd]`), pueden enviar notificaciones; son clientes directos del modelo y deben ser **finos**. Si crecen, la lógica de dominio se está escapando y el modelo se vuelve anémico [IDDD cap. 4]. Detalle en `ddd-skills/ddd-servicios-capa-aplicacion/GUIA.md`.
 
@@ -57,7 +57,7 @@ En la interfaz se valida formato (campo obligatorio, longitud), no conocimiento
 
 ## REST sin exponer el modelo
 
-Exponer el modelo directamente por REST produce interfaces frágiles: cada cambio del modelo rompe a los clientes. IDDD prefiere separar el modelo de la interfaz: recursos diseñados por casos de uso, construidos a partir de uno o varios agregados [IDDD cap. 4]. En TypeScript: el controlador comprueba la forma de la petición, llama a `execute` del caso de uso con su input, responde con lo que este devuelve (un id, un DTO o nada; nunca el agregado) y traduce los errores con `HttpErrorMapper` de `@archi-code/ddd/infrastructure` (404, 403, 409, 422…). Ejemplo en `ddd-skills/ddd-arquitectura/references/estructura-hexagonal-ts.md`.
+Exponer el modelo directamente por REST produce interfaces frágiles: cada cambio del modelo rompe a los clientes. IDDD prefiere separar el modelo de la interfaz: recursos diseñados por casos de uso, construidos a partir de uno o varios agregados [IDDD cap. 4]. En TypeScript: el controlador comprueba la forma de la petición, llama a `execute` del caso de uso con su input, responde con lo que este devuelve (un id, un DTO o nada; nunca el agregado) y traduce los errores según el `ExceptionKind` de `ExceptionClassifier.classify(error)` (`@archi-code/ddd/infrastructure`) a su protocolo (404, 403, 409, 422… en HTTP). Ejemplo en `ddd-skills/ddd-arquitectura/references/estructura-hexagonal-ts.md`.
 
 ## Señales de alarma
 

package/ddd-skills/ddd-arquitectura/assets/dependency-cruiser.cjs

@@ -3,8 +3,10 @@
  * Uso: npx depcruise src --config .dependency-cruiser.cjs
  * Funciona con src/contexts/<contexto>/ y con src/app/contexts/<contexto>/ (proyectos con la lógica en src/app/).
  * Probado con dependency-cruiser 16.10.0 y TypeScript 5.6, con un paquete simulado que expone
- * @archi-code/ddd/{domain,application,infrastructure,exceptions}. Si la estructura publicada del
+ * @archi-code/ddd/{domain,application,infrastructure}. Si la estructura publicada del
  * paquete difiere, ajusta ARCHI_LAYER.
+ * Cada subpath exporta las excepciones de su capa: cada capa importa solo el subpath de su capa y
+ * los interiores (domain → /domain; application → /domain y /application; infraestructura → todos).
  */
 // Grupo no capturante para app/: así $1 en las reglas es siempre el nombre del contexto.
 const CTX = '^src/(?:app/)?contexts/([^/]+)/';
@@ -16,7 +18,7 @@ module.exports = {
     {
       name: 'domain-solo-paquetes-permitidos',
       comment:
-        'El dominio solo usa @archi-code/ddd (domain y exceptions) y @archi-code/validation; nada más de npm.',
+        'El dominio solo usa @archi-code/ddd/domain (también sus excepciones) y @archi-code/validation; nada más de npm.',
       severity: 'error',
       from: { path: CTX + 'domain/' },
       to: {
@@ -26,7 +28,9 @@ module.exports = {
     },
     {
       name: 'domain-sin-capas-exteriores-del-paquete',
-      comment: 'El dominio nunca importa @archi-code/ddd/application ni @archi-code/ddd/infrastructure.',
+      comment:
+        'El dominio nunca importa @archi-code/ddd/application ni @archi-code/ddd/infrastructure ' +
+        '(tampoco sus excepciones).',
       severity: 'error',
       from: { path: CTX + 'domain/' },
       to: { path: ARCHI_LAYER('application|infrastructure') },
@@ -39,7 +43,9 @@ module.exports = {
     },
     {
       name: 'application-sin-infraestructura',
-      comment: 'La aplicación no conoce adaptadores propios ni @archi-code/ddd/infrastructure.',
+      comment:
+        'La aplicación no conoce adaptadores propios ni @archi-code/ddd/infrastructure ' +
+        '(tampoco InternalErrorException; un error ajeno lo envuelve UseCase en UnexpectedErrorException).',
       severity: 'error',
       from: { path: CTX + 'application/' },
       to: { path: [CTX + '(?:infrastructure|interfaces)/', ARCHI_LAYER('infrastructure')] },
@@ -47,8 +53,9 @@ module.exports = {
     {
       name: 'interfaces-no-saltan-a-infraestructura',
       comment:
-        'Los puntos de entrada llaman a casos de uso; no importan repositorios ni adaptadores. ' +
-        'Pueden importar HttpErrorMapper de @archi-code/ddd/infrastructure.',
+        'Los puntos de entrada llaman a casos de uso; no importan repositorios ni adaptadores propios. ' +
+        'De @archi-code/ddd/infrastructure solo usan ExceptionClassifier y ExceptionKind para traducir ' +
+        'los errores (dependency-cruiser no distingue nombres importados: revísalo en la revisión de código).',
       severity: 'error',
       from: { path: CTX + 'interfaces/' },
       to: { path: CTX + 'infrastructure/' },

package/ddd-skills/ddd-arquitectura/references/estilos-adicionales.md

@@ -32,13 +32,13 @@ Más detalle en `ddd-skills/ddd-event-sourcing-cqrs/GUIA.md`.
 
 Contextos que se comunican publicando y consumiendo eventos de dominio. Es la base de la integración robusta descrita en `ddd-skills/ddd-context-mapping/GUIA.md` y del diseño de `ddd-skills/ddd-eventos-dominio/GUIA.md`. Dentro de un contexto, los eventos también desacoplan efectos secundarios del caso de uso: el caso de uso llama a `events.publish(order.pullDomainEvents())` después de `await this.orders.save(order)` y un listener (`PrepareShipmentOnOrderLineAdded`) ejecuta la acción siguiente.
 
-Con el paquete, la tecnología es un `EventChannel` del proyecto (`RabbitMqEventChannel`, un relay que entrega el outbox que el repositorio escribió junto al agregado…) bajo el mismo `DomainEventBus`; en tests, `InMemoryEventChannel`. Hacia otros contextos no viaja `event.toJSON()` de la clase de dominio: el adaptador que habla con el broker lo traduce a un contrato publicado y versionado (`sales.order.OrderPlaced`) [IDDD cap. 13], algo que el paquete no da y escribe el proyecto. `[Fuera de los libros: convención de @archi-code/ddd]`
+Con el paquete, la tecnología es un `EventChannel` del proyecto (`RabbitMqEventChannel`, un relay que entrega el outbox que el repositorio escribió junto al agregado…) bajo el mismo `DomainEventBus`; en tests, `InMemoryEventChannel`. Hacia otros contextos no viaja el evento de dominio tal cual (`{ ...event }`): el adaptador que habla con el broker lo traduce a un contrato publicado y versionado (`sales.order.OrderPlaced`) [IDDD cap. 13], algo que el paquete no da y escribe el proyecto. `[Fuera de los libros: convención de @archi-code/ddd]`
 
 ## Event Sourcing
 
 El estado de un agregado se guarda como la secuencia de sus eventos y se reconstruye aplicándolos [Destilado cap. 6; IDDD cap. 4]. Aporta historial completo y auditoría, pero cambia por completo la persistencia y las consultas. Ver `ddd-skills/ddd-event-sourcing-cqrs/GUIA.md` antes de decidir.
 
-El paquete no trae event store: cada repositorio guarda el `toPrimitives()` del agregado junto a su `version`, que crece 1 por cada `save`, no por evento. Un agregado con Event Sourcing sigue extendiendo `AggregateRoot` y registrando con `record()`, pero su repositorio (en `infrastructure/`, implementando `AggregateFinder`/`AggregateSaver`) lleva la versión del flujo él mismo y reconstruye el agregado aplicando sus eventos, no con `toPrimitives()`/`fromPrimitives()`. `[Fuera de los libros: convención de @archi-code/ddd]`
+El paquete no trae event store: cada repositorio guarda el `toPrimitives()` del agregado junto a la versión que él mismo lleva (en su `WeakMap`), que crece 1 por cada `save`, no por evento. Un agregado con Event Sourcing sigue extendiendo `AggregateRoot` y registrando con `record()`, pero su repositorio (en `infrastructure/`, implementando `AggregateFinder`/`AggregateSaver`) lleva la versión del flujo él mismo y reconstruye el agregado aplicando sus eventos, no con `toPrimitives()`/`fromPrimitives()`. `[Fuera de los libros: convención de @archi-code/ddd]`
 
 ## Tabla de decisión