DDD - Чи обробляє агрегатор кореневого сховища збереження агрегатів?

Я використовую DDD-подібний підхід для greenfield модуля існуючої програми; це не 100% DDD завдяки архітектурі, але я намагаюся використовувати деякі поняття DDD. У мене обмежений контекст (я думаю, що це правильний термін - я все ще вчуся про DDD), що складається з двох об'єктів: Conversationі Message. Бесіда - це корень, оскільки Повідомлення не існує без розмови, і всі повідомлення в системі є частиною бесіди.

У мене є ConversationRepositoryклас (хоча він насправді більше схожий на шлюз, я використовую термін "сховище"), який знаходить розмови в базі даних; коли він знаходить розмову, він також створює (через Фабрики) список повідомлень для цієї розмови (виставляється як властивість). Це здається правильним способом поводження з речами, оскільки, мабуть, немає потреби в повномасштабному MessageRepositoryкласі, оскільки він існує лише тоді, коли ви знайдете розмову.

Однак якщо мова йде про збереження Повідомлення, чи несе ця відповідальність ConversationRepository, оскільки це сукупний корінь Повідомлення? Що я маю на увазі, чи повинен я мати метод ConversationRepository, який називається, AddMessageякий приймає повідомлення як його параметр і зберігає його в базі даних? Або я повинен мати окремий сховище для пошуку / збереження повідомлень? Здається, що логічна річ - це одне сховище на кожну організацію, але я також чув "одне сховище за контекстом".

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

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

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

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

ConversationRepository буде грати роль у збереженні Повідомлень, але не настільки прямої ролі, як ви згадуєте. Отже, жодного AddMessage () у ConversationRepository (цей метод швидше не належить до самої Conversation), але замість цього, кожен раз, коли репозиторій буде зберігати розмову, є хорошою ідеєю зберігати свої повідомлення одночасно, або прозоро, якщо ви використовуєте рамку ORM наприклад (N) у сплячому режимі, використовуючи спеціальний SQL, якщо ви вибрали таке рішення тощо.

Ви можете створити ConversationService і впровадити IConversationRepository і IMessageRepository в своєму конструкторі. Використовуйте сховища для простих операцій CRUD та служб для всього іншого (кешування, логіка збереження тощо)