Определение размера и ответственности репозитория и агрегата в архитектуре DDD

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

Допустим, у меня есть следующие (упрощенные) таблицы:

  • клиент [идентификатор, имя, идентификатор группы, идентификатор категории]
  • Группа клиентов [идентификатор, имя]
  • CustomerCategory [идентификатор, имя]

Основные функции (просто для демонстрации примеров использования методов)

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

Вопрос

Должен ли я рассматривать группу клиентов и категорию как отдельные агрегаты с:

  • Клиентский репозиторий. С помощью методов GetAllCustomers, GetCustomerById и т. д.

  • Репозиторий группы клиентов. С методами GetAllCustomerGroups, GetOneCustomerGroup

  • Репозиторий категорий клиентов. С методами GetAllCustomerCategories, GetOneCustomerCategory

Или только один репозиторий — CustomerRepository (со всеми вышеуказанными методами, более явно названными).

Слой выше в любом случае будет одним CustomerService с одним или несколькими репозиториями выше.

Мне бы хотелось получить некоторую информацию о том, как думать о размере совокупных и связанных данных (категорий, групп) с плюсами и минусами мелкозернистых репозиториев или нет. По-прежнему сохраняя простоту и сосредотачиваясь на решении проблем хорошим способом без чрезмерной архитектуры.

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


architecture domain-driven-design aggregateroot ddd-repositories
person Martin    schedule 24.03.2016    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Для этой области нет конкретной агрегированной модели, поскольку она в основном иерархична. По сути, у вас просто есть глупые структуры данных внутри контейнеров внутри других контейнеров. Никаких инвариантов или бизнес-правил в поле зрения, никаких намеков на части, которые будут находиться под значительным одновременным доступом.

Если это все, что есть в этой области, я бы не стал использовать тактические шаблоны DDD для ее моделирования, это просто CRUD.

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

person guillaume31    schedule 24.03.2016
comment
Я полностью согласен, чтобы не перепроектировать что-то. В данном случае это нечто большее, это часть довольно (слишком) большого приложения, в котором уже используются репозитории и службы DDD, и у них есть довольно много бизнес-правил. Но мне нравится ваша точка зрения, и я попытаюсь увидеть, могут ли части контекста быть CRUD, чтобы сохранить это простым, не отклоняясь от установленной архитектуры в этом контексте. - person Martin; 29.03.2016

arrow_upward
3
arrow_downward

Может ли пользователь создать категорию без клиентов? Если вы ответите «да», то категория является корневым агрегатом и должна иметь собственный репозиторий.

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

person jgauffin    schedule 24.03.2016
comment
Отличный точный вопрос, спасибо. В настоящее время ответ - нет, поэтому пока я буду держать его простым в одном репо. Если это изменится - последует рефакторинг. - person Martin; 29.03.2016