Aggregates и инварианты

Что aggregate применяет

Aggregate — это не группировка связанных данных. Это группировка данных вокруг инварианта согласованности — бизнес-правила, которое должно оставаться верным для нескольких объектов после каждой операции.

Aggregate Quote применяет правило: «суммарная согласованная стоимость всех позиций не должна превышать кредитный лимит клиента в момент подачи». Это правило охватывает Quote и все его объекты LineItem. Quote не может делегировать проверку в LineItem, потому что LineItem не знает о суммарной стоимости. Ни один отдельный LineItem не может нарушить правило — только коллекция в целом.

Это определяющий критерий для aggregate: какой наименьший набор объектов необходимо загрузить и заблокировать вместе, чтобы применить конкретный бизнес-инвариант? Этот набор и есть aggregate. Объект в корне этого набора, тот, что применяет инвариант, — aggregate root.

Aggregate root — единственная точка входа для внешнего кода. Ни один объект снаружи aggregate не держит прямую ссылку на внутренний LineItem. Внешний код вызывает quote.addLineItem(...) или quote.removeLineItem(...). Root Quote запускает проверку инварианта. Объекты LineItem — детали реализации: к ним нельзя обратиться, изменить или удалить, минуя root.

Одна транзакция изменяет один aggregate

Это правило — структурное следствие границы согласованности. Если одна транзакция изменяет два aggregate’а, то либо:

1. Вы поместили неправильные объекты в один aggregate (инвариант на самом деле охватывает оба — они должны быть одним aggregate’ом), либо
2. Вы приняли eventual consistency между двумя aggregate’ами (инвариант не должен применяться синхронно сразу для обоих — они коммуницируют через события).

Правило «одна транзакция — один aggregate» объясняет, почему batch-задание из вступительной истории породило проблему. Оно изменяло LineItem в одной транзакции, не проходя через Quote. Проверка инварианта Quote никогда не запускалась. Решение: убрать прямые записи LineItem полностью — все мутации идут через Quote.addLineItem() или Quote.updateLineItemPrice(), которые применяют инвариант после каждого изменения.

Ссылки на другие aggregate’ы по ID

Когда одному aggregate’у нужно ссылаться на другой, он делает это только через идентификатор — не через ссылку на объект. Aggregate Quote в Sales может ссылаться на Customer, которому принадлежит. Но Customer — отдельный aggregate (со своими инвариантами вокруг кредитной истории и статуса аккаунта). Aggregate Quote хранит customerId — value object, оборачивающий идентификатор клиента, — а не прямую ссылку на объект Customer.

Это имеет три следствия:

1. Нет каскадной загрузки: загрузка Quote не загружает автоматически граф Customer. Каждый aggregate загружается независимо.
2. Нет каскадной мутации: aggregate root может применять инварианты только над объектами, которыми владеет. Он не может мутировать Customer через ссылку — для этого нужно обращаться к Customer через его собственный root.
3. Явная кросс-aggregate согласованность: если операция должна изменить и Quote, и Customer — эти изменения происходят в отдельных транзакциях, координируемых через доменные события (событие QuoteSubmitted может запустить процесс, обновляющий Customer.openQuoteCount). Это eventual consistency по замыслу.

Размер aggregate’а: по инварианту, а не по графу данных

Самая распространённая ошибка в дизайне aggregate’ов — делать их слишком большими. Команды смотрят на граф объектов — Quote содержит LineItems, LineItems содержат Products, Products содержат PricingRules, PricingRules содержат Tiers — и объединяют всё в один большой aggregate, потому что «всё это связано».

Правильный вопрос размера: каков инвариант, который должен выполняться транзакционно? Если инвариант — «суммарная стоимость позиций не должна превышать кредитный лимит при подаче», то aggregate — это Quote + LineItems. Всё. Product — отдельный aggregate: его собственные правила (название, описание, статус в каталоге) никак не связаны с правилом кредитного лимита Quote. PricingRule — вероятно, тоже отдельный aggregate. Quote хранит ссылку productId и value object NegotiatedPrice — он не владеет Product.

Малые aggregate’ы имеют два критических преимущества:

Конкуренция за блокировки: большой aggregate блокируется на всё время транзакции. Если aggregate Order содержит каждую позицию, каждую отгрузку, каждый платёж и весь журнал взаимодействий с клиентом — тогда каждая операция над заказом блокирует весь заказ. В нагруженной системе это создаёт узкие места сериализации. Малые aggregate’ы блокируют только то, что нужно заблокировать для конкретного инварианта.

Концептуальная ясность: большой aggregate, объединяющий несвязанные вещи, — сигнал о том, что инварианты не были чётко определены. «Всё про заказ» — не инвариант. «Согласованная стоимость Quote не должна превышать кредитный лимит клиента» — это инвариант. Aggregate’ы, размер которых определяется инвариантом, делают бизнес-правила видимыми в коде.

Умолчание для размера aggregate’а: настолько мал, насколько позволяет инвариант. Начните с наименьшего aggregate’а, применяющего инвариант. Расширяйте только когда реальный инвариант этого требует — не когда граф объектов это предполагает.