Як слід додати / створити * команди в CQRS + Sourcing архітектурі

Я хочу реалізувати свою першу заявку за допомогою шаблону CQRS разом із пошуком подій. Мені цікаво, як зі створенням сукупних коренів слід правильно поводитися. Скажімо, хтось надсилає команду CreateItem. Як з цим поводитися? Де подію ItemCreate слід зберігати? Як перша подія нового предмета? Або я повинен мати якусь сутність ItemList, яка агрегує всі елементи та її список подій складається лише з подій ItemCreate?

Уді Дахан пропонує не створювати сукупні корені і завжди використовувати замість цього якийсь метод отримання. Але як я можу отримати щось нове і, звичайно, не присвоєно жодного посвідчення особи. Я розумію ідею, і цілком розумно думати, що новий об’єкт - це об'єкт, який має свій стан, що складається з нульових подій, на які відповіли. Але як я повинен його використовувати? Чи повинен я мати у своєму сховищі окремий метод, як-от getNewItem()чи зробити так, щоб get(id)метод Optional<ItemId>замість цього прийняв ?

Редагувати: Через деякий час копання я виявив справді цікаву реалізацію вищезазначених зразків за допомогою акторів. Автор замість створення агрегату витягує його з якогось сховища з новоствореним UUID. Недолік такого підходу полягає в тому, що він допускає тимчасовий стан невідповідності. Мені також цікаво, як я можу реалізувати deleteметод з таким підходом. Просто додайте Видалену подію до списку подій у сукупності?

Як я збираюсь, на посаді Уді ідеться, що жоден предмет не з’являється з повітря. Завжди (майже) завжди є щось, або точніше, деяка операція над доменом, яка спричинила створення елемента. Так само, як приклад Уді про те, що користувач насправді народжується з відвідувача, який реєструється на сайті. У цей момент і в цьому обмеженому контексті відвідувач - це сукупний корінь, який отримується за його IP-адресою. Потім цей Відвідувач створює новий "елемент", користувач в цей момент, через операцію над доменом під назвою Зареєструватися . Те ж саме стосується і попереднього кроку, що є ще одним обмеженим контекстом: Довідник - це AR, який отримується за URL-адресою і має доменну операцію під назвою BroughtVisitorWithIp , де відвідувач народився.

Уді дуже добре пише і про видалення: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/ . Головна ідея полягає в тому, що ви нічого не видаляєте ніколи. Завжди є операція над доменом, яку ми хочемо захопити. Наче замовлення скасовується, а не видаляється. Прочитайте, це дуже хороший пост.

Основний момент, що стосується обох облікових записів - DDD, і особливо Sourcing подій, - це те, що ви ніколи не повинні робити прямі CRUD-операції. Якщо ви опинитесь у ситуації, коли вам дійсно потрібно просто вставити, оновити або видалити деякі дані, і за цим дійсно немає операцій над доменом, можливо, DDD та події Sourcing не дуже підходять для цього обмеженого контексту . Ви можете поєднувати ці два, як хочете, до тих пір, поки один обмежений контекст дотримується одного принципу. Таким чином, обмежений контекст у стилі CRUD може створити певну рядок у базі даних, який стає сутністю та зведеним коренем у іншому обмеженому контексті, де тепер можна отримати AR та не потрібно його створювати.