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

Question

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

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

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

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

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

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

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

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

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

Что здесь за DDD?

Answer 1

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

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

Что ты думаешь?

Обновление

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

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

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

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

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

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