Що таке сукупний корінь?

Я намагаюсь поглянути на те, як правильно використовувати шаблон сховища. Центральна концепція агрегованого кореня продовжує формуватися. Коли я шукаю як Інтернет, так і стек-переповнення, щоб отримати допомогу щодо того, що таке сукупний корінь, я постійно знаходжу дискусії про них та мертві посилання на сторінки, які повинні містити базові визначення.

Що стосується шаблону сховища, що таке сукупний корінь?

У контексті шаблону репозиторію сукупні корені - це єдині об'єкти, які ваш клієнтський код завантажує із сховища.

Репозиторій інкапсулює доступ до дочірніх об'єктів - з точки зору абонента, він автоматично завантажує їх, або одночасно завантажується корінь, або коли вони фактично потрібні (як при ледачому завантаженні).

Наприклад, у вас може бути Orderоб'єкт, який капсулює операції над декількома LineItemоб'єктами. Ваш клієнтський код ніколи не завантажуватиме LineItemоб'єкти безпосередньо, лише той, Orderщо їх містить, який був би сукупним коренем для тієї частини вашого домену.

Від Еванса DDD:

АГРЕГАТЕ - це сукупність пов’язаних об'єктів, які ми розглядаємо як одиницю з метою зміни даних. Кожен АГРЕГАТ має корінь і межу. Межа визначає, що знаходиться всередині АГРЕГАТИ. Корінь - це єдиний, специфічний ENTITY, що міститься в АГРЕГАТІ.

І:

Корінь є єдиним членом АГРЕГАТИ, на зовнішніх об'єктах дозволено мати посилання на [.]

Це означає, що сукупні корені - це єдині об'єкти, які можна завантажити з сховища.

Приклад - модель, що містить Customerсутність та Addressсутність. Ми ніколи не звертаємось до Addressсутності безпосередньо із моделі, оскільки це не має сенсу без контексту пов'язаного Customer. Отже, ми могли б сказати, що Customerі Addressразом утворюють сукупність і Customerце сукупний корінь.

Зведений корінь - це складна назва простої ідеї.

Загальна ідея

Добре розроблена схема класу інкапсулює її внутрішні місця. Точка, через яку ви отримуєте доступ до цієї структури, називається aggregate root.

Внутрішнє рішення вашого рішення може бути дуже складним, але користувач цієї ієрархії просто використовуватиме root.doSomethingWhichHasBusinessMeaning().

Приклад

Перевірте цю просту ієрархію класів

Як ти хочеш їздити на своєму автомобілі? Вибирали краще api

Варіант A (він просто якось працює):

car.ride();

Варіант B (користувач має доступ до інернацій класу):

if(car.getTires().getUsageLevel()< Car.ACCEPTABLE_TIRE_USAGE)
    for (Wheel w: car:getWheels()){
        w.spin();
    }
}

Якщо ви вважаєте, що варіант А краще, то вітайте. Ви отримуєте головну причину позаду aggregate root.

Сукупний корінь інкапсулює декілька класів. ви можете маніпулювати цілою ієрархією лише через основний об'єкт.

Уявіть, що у вас є комп'ютерна організація, ця організація також не може жити без свого програмного забезпечення та апаратного забезпечення. Вони утворюють Computerсукупність, міні-екосистему для комп’ютерної частини домену.

Зведений корінь - це сукупність материнства всередині сукупності (в нашому випадку Computer), загальною практикою є те, щоб ваш репозитарій працював лише з сутностями, які є агрегованими коренями, і ця сутність відповідає за ініціалізацію інших сутностей.

Розгляньте корінь агрегації як вхідну точку до агрегату.

У коді C #:

public class Computer : IEntity, IAggregateRoot
{
    public Hardware Hardware { get; set; }
    public Software Software { get; set; }
}

public class Hardware : IEntity { }
public class Software : IValueObject { }

public class Repository<T> : IRepository<T> where T : IAggregateRoot {}

Майте на увазі, що апаратне забезпечення, ймовірно, теж буде ValueObject (не маєте ідентичності самостійно), розгляньте це лише як приклад.

Якщо ви дотримуєтесь підходу, який базується на першій базі даних, ваш агрегатний корінь зазвичай є таблицею з 1 боку відносини 1-багато.

Найпоширеніший приклад - бути Особою. У кожної людини є багато адрес, один або кілька квитанцій про оплату, рахунки-фактури, записи CRM тощо. Це не завжди так, але це 9/10 разів.

Зараз ми працюємо на платформі електронної комерції, і в основному ми маємо два сукупні корені:

1. Клієнти
2. Продавці

Клієнти надають контактну інформацію, ми присвоюємо їм транзакції, транзакції отримують позиції тощо.

Продавці продають товари, мають контактних людей, сторінки про нас, спеціальні пропозиції тощо.

Про них опікується відповідно Клієнт та Продавець.

Діна:

У контексті репозиторію зведений корінь - це сутність, яка не має жодної батьківської сутності. Він містить нуль, одне або багато дочірніх утворень, існування яких залежить від батьків за його особистістю. Це відносини один до багатьох у сховищі. Ці дочірні організації є простими агрегатами.

З розірваного зв’язку :

Всередині агрегату є агрегований корінь. Кореневий агрегат є батьківською сутністю для всіх інших об'єктів та об'єктів цінності в агрегаті.

Репозиторій працює на агрегованому корені.

Більше інформації можна знайти тут .

Сукупність означає збір чогось.
root - як верхній вузол дерева, звідки ми можемо отримати доступ до всього, як <html>вузол у документі веб-сторінки.
Аналогія блогу, Користувач може мати багато дописів, і кожен допис може мати багато коментарів. тож якщо ми забираємо будь-якого користувача, він може діяти як root для доступу до всіх пов’язаних публікацій та подальших коментарів до цих публікацій. Вони всі разом називають збірними або зведеними

Сукупність - це те, де ви захищаєте свої інваріанти і змушуєте послідовність, обмежуючи його доступний корінний корінь думки. Не забувайте, що агрегат повинен розробляти правила вашого бізнесу та інваріанти, а не взаємозв'язок із базою даних. не слід вводити жодне сховище, і жодні запити не дозволені.

У Ерланге немає необхідності розмежовувати агрегати, як тільки агрегат складається із структур даних всередині держави замість складу ОО. Дивіться приклад: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london