Какие объекты должны быть Агрегированными Корнями? - PullRequest
Новая
       6

Какие объекты должны быть Агрегированными Корнями?

1 голос
/ 18 марта 2010

Если Book агрегирует главу, которая в свою очередь агрегирует Page, то каким должен быть корень агрегирования? Одна возможность может быть:

Книга - это совокупный корень с главой в качестве листа, а глава - агрегат с страницей в качестве листа.

В этом сценарии Chapter - это лист в одном агрегате и корень в другом. Это нормально? Имеет ли смысл в этом сценарии иметь два хранилища: одно для Книги, а другое для Главы? Если это так, то нельзя ли использовать репозиторий Chapter, чтобы обойти тот факт, что доступ к Chapter должен осуществляться только через Book? Как лучше всего справиться с такой ситуацией?

1 Ответ

2 голосов
/ 19 марта 2010

По моему мнению, вся идея корней совокупности имеет смысл только тогда, когда для данного агрегата существует единый корень. Какой из них - зависит от ваших требований. Давайте рассмотрим две возможности:

  1. Книга является корнем и содержит главы, содержащие страницы. Этот дизайн полезен, когда все ваши сценарии использования включают взаимодействие с книгами: пользователи выбирают книги и применяют свои операции / команды ко всем книгам. Обратите внимание, что агрегат Book находится на уровне «операций» модели вашего домена - в целом он представляет понятия, которые являются частью повседневного бизнеса.

  2. Глава это корень. Содержит Страницы. Это также имеет ссылку на книгу. Этот дизайн полезен, когда сценарии использования сосредоточены на взаимодействии с отдельными главами. Агрегат глав теперь находится в слое «операций». Книга сама по себе формирует совокупность, но находится под слоем «потенциал / возможности» под слоем операций. Это означает, что книги являются активом организации, инструментом для бизнеса, но не являются частью повседневной деятельности. Более того, книги ничего не знают о ссылках на главы.

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

»
...