Агрегат описують через межу узгодженості: група об'єктів, яку зберігають і завантажують як одне ціле, бо інакше бізнес-правило не гарантувати. Корінь агрегату - сутність, через яку з ним розмовляє весь зовнішній код; внутрішні сутності не мають публічних репозиторіїв і напряму не змінюються. Усе це заради того, щоб після кожної успішної транзакції стан агрегату був валідним. Якщо Order каже «сума позицій не перевищує кредитний ліміт», додати позицію можна лише методом addLine(), бо тільки там видно всі позиції одночасно.
Звідси й критерій межі. Випишіть інваріанти і для кожного запитайте, чи він мусить виконуватися в момент коміту, чи може побути порушеним кілька секунд. «Сума рядків дорівнює підсумку документа» порушитися не може взагалі, тому рядки лежать всередині. «На складі є залишок» у реальному житті порушується, у бізнесу є процедура на цей випадок (скасування, довезення), тому резерв виносять в окремий агрегат, а узгодження йде подією. Решта зв'язків, якими розробники зазвичай мотивують великий агрегат («у клієнта ж є замовлення»), це навігація по даних, і її місце в read-моделі, а не в межі транзакції.
Правило «один агрегат на транзакцію» випливає з попереднього. Якщо одна транзакція змінює два агрегати, ви неявно оголосили, що між ними теж є інваріант, і тоді незрозуміло, навіщо вони окремі. На практиці звідси береться ще й свобода розміщення: поки Order і Shipment комітяться окремо, їх можна рознести по модулях або базах без переписування домену. Зв'язок між кроками гарантує збережене повідомлення, а не база: рядок в outbox у тій самій транзакції, воркер, обробник. Якщо друга дія може провалитися бізнесово, потрібна явна компенсація замість rollback.
Посилання на інші агрегати тримають ідентифікатором, і причина тут суто практична. Живий об'єкт у полі змушує репозиторій тягнути чужу таблицю, рано чи пізно його змінюють, і в коміт потрапляє другий агрегат. Типізований CustomerId замість int додає ще й перевірку на етапі статичного аналізу: PHPStan не дасть передати OrderId там, де чекають клієнта. Коли методу агрегату справді потрібні дані з-за межі, їх передають аргументом - $order->applyDiscount(CustomerTier::Gold), рішення ухвалює application-сервіс, який цей рівень прочитав.
Ціна завеликого агрегату видна в продакшені раніше, ніж у дизайні. Усі записи в нього серіалізуються: з версією на корені два одночасні запити дають ConcurrentModification одному з них, навіть якщо вони торкалися зовсім різних полів; з песимістичним SELECT ... FOR UPDATE другий чекає й упирається в lock wait timeout. Колекції всередині теж мають свою ціну: агрегат завантажується цілком, тому hasMany на тисячі рядків означає тисячі рядків у пам'яті на кожну зміну статусу. Класичний приклад з книг - Product з усіма Review: інваріанта між ними немає, рейтинг рахується окремо, а розмір росте нескінченно. Коли інваріант вимагає не самої колекції, а лише суми чи кількості, у корені тримають це похідне значення, а рядки виносять за межу.
Оптимістичне блокування згадують разом з межами, бо без нього опис агрегату неповний. Правило перевіряється в пам'яті на завантаженій копії, тож між SELECT і UPDATE стан у базі міг змінитися: два паралельні addLine() прочитають однакову суму, кожен визнає ліміт дотриманим, і обидва запишуться. Умова WHERE version = ? з перевіркою affected rows робить конфлікт видимим; у Doctrine це #[Version], у Laravel пишеться руками. Невдалі апдейти корисно логувати з розбивкою по методах - саме ці лічильники показують, де межа агрегату проведена надто широко.
// Корінь агрегату: позиції всередині, бо від них залежить інваріант суми
final class Order
{
/** @var list<OrderLine> */
private array $lines = [];
private function __construct(
private readonly OrderId $id,
private readonly CustomerId $customerId, // інший агрегат - лише id
private readonly Money $creditLimit,
private OrderStatus $status,
private int $version, // для оптимістичного блокування
) {}
/**
* Єдиний спосіб додати позицію: інваріант перевіряється тут, а не в контролері.
*
* @throws OrderAlreadyPaid|CreditLimitExceeded
*/
public function addLine(Sku $sku, int $quantity, Money $unitPrice): void
{
if ($this->status !== OrderStatus::Draft) {
throw new OrderAlreadyPaid($this->id);
}
$line = new OrderLine($sku, $quantity, $unitPrice);
$total = $this->total()->plus($line->amount());
if ($total->greaterThan($this->creditLimit)) {
throw new CreditLimitExceeded($this->id, $total, $this->creditLimit);
}
$this->lines[] = $line; // стан змінюється лише після перевірок
}
/** Копія назовні: зовнішній код не має доступу до внутрішніх об'єктів */
public function total(): Money
{
return array_reduce(
$this->lines,
static fn (Money $sum, OrderLine $line): Money => $sum->plus($line->amount()),
Money::zero($this->creditLimit->currency()),
);
}
}
// Репозиторій: один UPDATE на агрегат, версія - умова, а не просто колонка
public function save(Order $order): void
{
$affected = $this->db->update(
'UPDATE orders SET status = ?, total_minor = ?, version = version + 1
WHERE id = ? AND version = ?',
[$order->status()->value, $order->total()->minor(), $order->id(), $order->version()],
);
if ($affected === 0) {
throw new ConcurrentModification($order->id());
}
}Назвіть інваріант уголос і запитайте, чи він має виконуватися в момент коміту. «Сума позицій не більша за ліміт замовлення» - має, значить позиції всередині `Order`. «Товару на складі достатньо» - не зобов'язаний, бо склад змінюють інші люди й інші процеси, значить резервування живе в окремому агрегаті й узгоджується подією. Додайте, що агрегат ви перевіряєте на двох одночасних запитах: якщо правило ламається без версії на корені, межа описана, а механізм захисту ні.