Какой лучший способ отделить агрегат в DDD

Question

Я изучаю DDD, я не понимаю, как разделить объекты в совокупности.

Пример:

У меня есть 3 объекта: компания, магазин, работа.

И у меня есть некоторые отношения: у одной компании есть много магазинов, и у одного магазина есть много рабочих мест.

Я думаю:

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

Работа - это еще одна совокупность.

Еще одна мысль

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

Компания является еще одним агрегатом.

Какой путь правильный?

Спасибо

Answer 1

Единственный возможный ответ, конечно, "это зависит". Это не особенно полезно, хотя.

Просмотрите определение совокупности из книги Эвана:

AGGREGATE - это кластер связанных объектов, которые мы рассматриваем как единое целое для целей изменения данных... Инварианты, которые представляют собой правила согласованности, которые должны поддерживаться при любых изменениях данных, будут включать отношения между членами AGGREGATE. Предполагается, что любое правило, которое охватывает AGGREGATES, не будет постоянно обновляться... Но инварианты, применяемые в AGGREGATE, будут принудительно применяться по завершении каждой транзакции.

Итак, вопросы "какие объекты составляют мой агрегат" и "каков мой агрегатный корень?" зависит от того, какие бизнес-инварианты должны применяться в отношении каких бизнес-транзакций?

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

Посмотрите на ваши требования. Посмотрите, какие типы поведения должна поддерживать ваша система. Что вы можете сделать с работой? Создать их? Запустить их? Завершить их? Можете ли вы перевести работу из одного магазина в другой? Может ли работа переместиться между компаниями?

Какие факты должны быть последовательными? Например, вы устанавливаете максимальное количество рабочих мест в магазине? В конце "добавления работы", должно ли текущее количество рабочих мест в магазине соответствовать назначению работы магазина?

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

Существует также компромисс между размером / областью действия агрегата и возможностью конфликта данных при обновлении агрегата в транзакции.

Со всеми этими вещами, о которых нужно беспокоиться, вы можете задаться вопросом, зачем вообще работать с агрегатами? Ну, они хороши в паре вещей:

• проверка и выполнение команд БЫСТРО, потому что все данные, которые вам нужны, находятся внутри агрегата.
• они хорошо подходят для постоянных хранилищ на основе документов (например, MongoDB с вложенными документами для объектов агрегации), что делает извлечение агрегатного состояния простым и производительным, а также упрощает реализацию границы агрегированных транзакций благодаря атомарным обновлениям на уровне документов
• их чрезвычайно легко протестировать, потому что они могут быть реализованы в виде простых классов (POCO /POJO в C# или Java). Поскольку они содержат большую часть вашей бизнес-логики, это означает, что поведение вашего приложения в целом также легко тестировать!
• они намерены; У каждого агрегата есть цель, и по данным и функциям, которые они реализуют, точно так же, как и в вашей системе, становится ясно. В сочетании с использованием вездесущего языка контекста, в котором вы кодируете, в самом коде, они являются наиболее прямым выражением вашего делового поведения в кодовой базе (гораздо больше, чем набор таблиц данных в одиночку)
• потому что они так специфичны для конкретного случая использования, агрегаты часто избегают негерметичных абстракций, которые возникают в более общих решениях

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