DDD - как следует обрабатывать объекты поиска?

Мы работаем над проектом с использованием DDD, но зацикливаемся на том, как обрабатывать объекты поиска. Например, у нас есть агрегат под названием «Клиент», а сущность «Клиент» также является корневым агрегатом. Сущность «Клиент» имеет свойство «CustomerTypeID».

Но у нас также есть сущность «CustomerType», представляющая все существующие типы клиентов (ID и описание). Будет функция администратора, позволяющая пользователям поддерживать типы клиентов (например, добавлять новый тип клиентов и т. Д.).

Обратите внимание, что я говорю не об изменении типа клиента для конкретного клиента, а о ведении списка типов клиентов.

Приношу свои извинения за долгую историю, но вот мои вопросы:

  • Прав ли я, думая, что «CustomerType» - это сущность, а не объект-значение?

  • должен ли «CustomerType» находиться внутри агрегированного «Customer» или должен быть внутри его собственного агрегата, поскольку мы будем получать к нему доступ и поддерживать его вне контекста конкретного клиента?

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

Как видите, я запутался здесь, и мне просто нужно указать правильное направление.

=================================== Я попытался написать код в ответ на ответ eulerfx, но не смог ' Чтобы заставить его работать, я положу его сюда.

Что касается пункта 2, на экране мы, очевидно, всегда будем показывать только описание типа (например, «Личный»). Значит ли это, что я получу что-то вроде этого ?:

Public Class Customer
    Inherits EntityBase(Of Integer)
    Implements IAggregateRoot

    Public Property CustomerID As Integer
    ...
    Public Property CustomerType As CustomerType
    ...

а также

Открытый класс CustomerType Наследует EntityBase (Of Integer) Реализует IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

Или свойство внутри класса «Customer» должно быть CustomerTypeID?

Что касается пункта 3, в чем разница между агрегированным и ограниченным контекстом? Разве агрегат «Клиент» (с «Клиентом» является агрегатным корнем), который также содержит любые сущности и объекты значений, которые существуют только в контексте Клиента, не будет ограниченным контекстом?


aggregate domain-driven-design aggregateroot
person Peter    schedule 06.12.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

  1. Да, поскольку CustomerType имеет идентификатор и соответствующее описание, это сущность.

  2. Имеет ли класс Customer свойство CustomerType или свойство CustomerTypeId, зависит от того, нужен ли ему доступ к другим свойствам на CustomerType. В любом случае CustomerType - это отдельная сущность, имеющая собственный репозиторий.

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

person eulerfx    schedule 07.12.2011
comment
Я пытаюсь добавить немного кода в комментарий, но, поскольку это мой первый пост, я немного борюсь. - person Peter; 07.12.2011
comment
все еще борется, поэтому я добавил раздел в конец исходного запроса. пожалуйста, посмотри - person Peter; 07.12.2011
comment
›Или свойство внутри класса Customer должно быть CustomerTypeID? Это зависит от того, нужен ли объекту «Клиент» доступ к описанию типа клиента. - person eulerfx; 08.12.2011
comment
›В чем разница между агрегированным и ограниченным контекстом? devlicio.us/blogs/casey/archive/ 2009/02/11 / - person eulerfx; 08.12.2011