DDD - как следует обращаться с объектами поиска? - PullRequest
Новая
       62

DDD - как следует обращаться с объектами поиска?

4 голосов
/ 06 декабря 2011

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

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

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

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

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

  • должен ли "CustomerType" быть внутри агрегата "Клиент" или он должен находиться внутри его собственного агрегата, так как мы будем обращаться к нему и поддерживать его вне контекста конкретного клиента?

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

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

=================================== Я попытался написать какой-то код в ответ на ответ 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, в чем разница между совокупным и ограниченным контекстом? Не будет ли агрегат «Клиент» (где «Клиент» является корнем агрегата), который также содержит какие-либо сущности и объекты значений, которые существуют только в контексте Клиента, не быть ограниченным контекстом?

1 Ответ

5 голосов
/ 07 декабря 2011

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

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

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

...