Точные вопросы и ответственность элементов DDD

Я видел много статей о DDD и множество шаблонов, описанных в книге Мартина Фаулера «Шаблоны архитектуры корпоративных приложений», но мне нужны ГУРУ РАЗРАБОТКИ по stackoverflow, чтобы понять несколько вещей.

Каковы основные (методы и функционалисты) = проблемы, которые должны быть включены в каждый из компонентов DDD, таких как (репозиторий, совокупный корень), и должен ли он делегировать его другому объекту?

Совокупный корневой объект, например. FaceBook, User - это совокупность корней, в которой хранятся объекты UserObject (вы), postObjects (созданные вами сообщения), pictureOBJects; Удерживает ли WORD означает, что оно удерживает его во внутреннем состоянии? или просто он содержит функцию, которая направляет вас к другому методу репозитория, включая, например, ваш идентификатор?

Потому что, если совокупный корень удерживает агрегированные объекты в своем внутреннем состоянии, что происходит, когда объект требуется в более чем 1 корне? (картинки тоже принадлежат фотогалерее) ,,, гррррр Я запуталась!

пожалуйста, опишите, например, дизайн домена Facebook (или любого другого веб-приложения), чтобы такие новички, как я, могли установить универсальный язык между опытными разработчиками и нами :)


oop object domain-driven-design aggregateroot
person Zalaboza    schedule 20.03.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Потому что, если агрегированный корень удерживает агрегированные объекты в своем внутреннем состоянии, что происходит, когда объект требуется более чем в 1 корне? (картинки тоже принадлежат фотогалерее) ,,, гррррр Я запуталась!

В DDD сущности не всегда являются частью агрегирования. Некоторые сущности, которые являются общими для многих агрегированных корней, являются корнями их собственных агрегатов. У них есть свои собственные репозитории, как и у любых агрегированных корней. Например, в синей книге Customer, Location и CarrierMovement - это общие сущности, которые являются корнями своих собственных агрегатов.

пожалуйста, опишите, например, дизайн домена Facebook (или любого другого веб-приложения), чтобы такие новички, как я, могли установить универсальный язык между опытными разработчиками и нами :)

Шаблоны DDD нельзя применять вслепую или в равной степени к любым приложениям, они зависят от того, как вы и ваша команда рассматриваете домен. Например, вы не должны использовать шаблон агрегации только потому, что в вашей модели есть отношения включения. Вы можете проектировать: Customer владеет Invoice, но вы также можете (что более вероятно) проектировать: Invoice имеет ссылку на Customer. Оба действительны в DDD.

Ваш дизайн должен действительно отражать область вашего приложения. Это должно совпадать с точкой зрения эксперта в вашей предметной области. Экспертом в предметной области можете быть вы сами, ваш клиент или кто-то, кого вы нанимаете, потому что он является экспертом в определенной области (например, бухгалтерский учет, здравоохранение, банковское дело и т. Д.). Наличие эксперта по предметной области в вашей команде является обязательным требованием для применения DDD. Если ваш домен недостаточно сложный, вам не понадобится DDD.

person jocki    schedule 11.04.2014