Управление доменом Дизайн - Хранилища и совокупные корни

Question

У меня есть модель домена, содержащая форум.

У меня есть форум, темы и сообщения.

Этот форум является самостоятельным субъектом. Т.е. он не содержит поток как часть совокупности. Это связано с тем, что потоки не принадлежат определенному форуму (вы можете перемещать поток на другой форум).

Я не знаю, должен ли я моделировать сообщения как часть агрегата потока. Сообщения не могут существовать без потока. Удалите поток, и вы должны удалить сообщения, которые сообщают мне, чтобы сообщения занимали часть агрегата потока.

Единственное, что сообщения также могут быть выбраны отдельно при их редактировании. Т.е. при редактировании сообщения его id.

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

Единственное, что имеет отдельный почтовый репозиторий, заключается в том, что при добавлении сообщений, то есть в addPost (Post), вам необходимо убедиться, что идентификатор потока был назначен объекту post. С агрегатом, я думаю, у вас просто будет метод addPost для объекта потока.

Должен ли я думать о ограниченных контекстах? Могу ли я иметь почтовый объект и репозиторий, а также иметь агрегат потоков, который также включает в себя почтовые объекты?

Если я не пошел с агрегатом потока/сообщения, как бы я обрабатывал удаление почты, когда я удаляю поток? Должен ли я создать службу, которая вызывает deleteThread (Thread) в репозитории потоков, и deletePostsByThreadId (id) в почтовом репозитории?

Что такое способ DDD?

Answer 1

Мне интересно, если в вашем случае DDD - хорошая идея. Я имею в виду, что форумы ориентированы на данные по природе. Возможно, вам следует рассмотреть простейший подход и просто использовать классические технологии, ориентированные на данные, для запроса ваших данных. (т. е. LINQ, Hibernate, простой SQL, инфраструктура сущности или все, что вы хотите, в зависимости от вашей формы)

Возможно, вам не нужен доменный уровень, или вы получите класс ForumDTO, который хранит данные, и Форум, который содержит бизнес-логику, то же самое для сообщения или потока, для меня это кажется анти-шаблоном.

Как вы думаете?

Update

Я рекомендую вам читать книгу от Эрика Эванс, он имеет большие примеры комплексной области, где DDD подходит очень хорошо. После прочтения этой книги я был в восторге от применения того, что я узнал, но я видел, что в некоторых случаях подход, ориентированный на данные, более уместен.

Для меня практически нет сложной логики домена для Форума, поэтому вы получите следующее: 1 < -> 1 сопоставление между вашим уровнем данных и уровнем домена, это означает дублирование и накладные расходы, как я сказал.

Просматривая описание вашего домена, ваш подход кажется ориентированным на данные. Например, интуитивно форум HAS threads и threads HAS posts, домен, как вы его описываете, не отражает этого, и вы, похоже, нормализуете свою объектную модель, чтобы она соответствовала вашей схеме базы данных (которая будет нормализована).

Форум кажется самым лучшим классом будет корнем совокупности (это более интуитивное)

Если вы действительно хотите использовать DDD подход, вы можете вводить репозитории в ваших сущностях, и дать свой домен объект Внушительные имя как thread.GetLastPostOf (Пользователь пользователя), в зависимости от ваших требований.

Но я согласен с вами, когда вы говорите, что у вас должен быть репозиторий с помощью метода GetPostById.