Должны ли значения поиска быть смоделированы как совокупные корни?

Как часть моей модели домена, скажем, у меня есть объект WorkItem. Объект WorkItem имеет несколько отношений к значениям поиска, например:

WorkItemType:

пользовательские истории
Ошибка
Улучшение

Priority:

High
Средние
Низкая

И может быть больше, например Status, Severity и т.д.

DDD заявляет, что если в корне агрегата существует что-то, что вы не должны пытаться получить к нему доступ за пределами корня aggregate. Поэтому, если я хочу иметь возможность добавлять новые теги WorkItemType, такие как Task, или новые приоритеты, такие как Critical, должны ли эти значения поиска быть агрегированными корнями со своими собственными репозиториями? Это кажется немного переполненным, особенно если они являются только ключевой парой значений. Как я могу разрешить пользователю изменять эти значения и соблюдать правила суммарного корневого инкапсуляции?

Ответ 1

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

Причины, по которым я думаю, что использование репозитория - это правильный способ:

Пользователь должен иметь возможность добавлять эти пары значений независимо от рабочего элемента.
Пары значений не имеют локального уникального идентификатора

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

Как примечание, хороший вопрос! В этой ситуации есть довольно много сообщений в блоге... Но не все согласны на лучший способ сделать это.

Ответ 2

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

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

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

Еще одна вещь, которую следует учитывать, - это модель модели для чтения, которая по существу позволяет использовать тип репозитория только для запросов, который эффективно отделяет модель домена, зависящую от поведения, от запросов.

Ответ 3

Не все должно быть смоделировано с использованием DDD. Сложность управления справочными данными, скорее всего, не оправдывала бы создание совокупных корней. Общим решением было бы использовать CRUD для управления ссылочными данными и иметь доменную службу для взаимодействия с этими данными из домена.

Ответ 4

У этих поисковых запросов есть идентификатор? Если нет, вы можете подумать о том, чтобы сделать их Объекты ценности...