DDD: Сколько мне нужно заполнить корни?

Question

Я немного запутался с концепцией «Агрегатный корень» в DDD. Теория говорит тогда, что это должен быть совокупный корень, который имеет отношение к текущей операции.

Например, у меня есть учетная запись root, которая представляет компанию. У него есть адрес, пользователи, принадлежащие учетной записи, некоторые другие свойства.

И у меня есть несколько страниц; один - управлять общей информацией, такой как имя, адрес электронной почты, телефон ... Другим является сохранение адреса. Еще один, чтобы показать всех пользователей (и отредактировать информацию о пользователе, которая, вероятно, также относится к объекту Account)

В первом случае меня не интересует адрес, на втором мне не важно имя, адрес электронной почты .. ..

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

Так, например, я могу закончить с классами: BasicAccountInformation, AccountAddress, AccountUsers .... Или только один: Счет, который содержит все данные?

Каков правильный подход DDD? Я думаю, что в одном случае я получу очень сложный класс, содержащий много свойств и логики; или множество простых классов с 2-10 свойствами на класс.

Answer 1

Сколько Агрегированных корней мне нужно?

По меньшей мере один.

Агрегаты служат границами согласованности. Если вы моделируете весь свой домен как единый агрегат и предоставляете один «совокупный корень», который гарантирует, что ваш бизнес-инвариант поддерживается каждой записью, вам хорошо идти.

Хорошо, вы можете идти медленно. Совокупный корень служит своего рода узким местом для сериализации для всего состояния на общей границе. Если вы ожидаете обновить две разные части модели «одновременно», тогда вам понадобится раздел ответственности за бизнес-инвариант.

И у меня есть страницы; один - управлять общей информацией, такой как имя, адрес электронной почты, телефон ... Другой - поддерживать адрес.

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

Но отчеты отвратительны, говоря вам, где ваши агрегаты - основная задача ваших агрегатов - не читать/представлять/не сообщать свои данные, а писать.

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

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

Вы можете посмотреть на отношения сущностей; если два агрегата «делят» сущность, то этот объект, вероятно, принадлежит к третьему агрегату.

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

Основываясь на том, что вы описали, это тоже не помогает; вы действительно получили отчет и кучу вещей, которые живут в нем.

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