Является ли структура (график) объектов Агрегированным Корнем, достойным Репозитория? - PullRequest
0 голосов
/ 15 марта 2012

Философский вопрос DDD здесь ...

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

Я сейчас работаю в финансовой сфере.У нас есть средства (разновидности хеджирования).Эти фонды часто инвестируют в другие фонды.Это приводит к некоторой древовидной структуре с одним фондом наверху, который связывает все это вместе.

Очевидно, что фонд является сущностью ( Совокупный корень , даже).Такие вещи, как сделки и позиции, скорее всего, являются объектами значения.

Мой вопрос: следует ли рассматривать саму древовидную структуру как совокупный корень?Некоторые мысли:

  • Древовидная структура хранится в БД путем хранения компонентов и положений, которые они имеют друг в друге.В настоящее время у нас нет закодированной концепции дерева.Домен очень слабый.
  • Древовидная структура не имеет «уникальности» или идентификатора.
  • Во многих местах необходима логика, чтобы «пройтись» по дереву, чтобы найти связи друг с другом,либо сверху вниз, либо иногда снизу вверх.Эту логику нужно где-то инкапсулировать.
  • Существует много логики для вычисления кредитного плеча, воздействия и т. Д. И свертывания его в дереве.рассматривать фонд как составной объект фонда, а это совокупный корень со встроенными инвариантами ?Или в этом случае полезна более формальная древовидная структура?

Ответы [ 2 ]

2 голосов
/ 16 марта 2012

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

В результате получается своего рода древовидная структура

Возможно, вы можете говоритьс вашим экспертом в области, чтобы узнать, заслуживает ли это понятие быть гражданином первого класса с собственным именем на вездесущем языке (FundTree, FundComposition ...?)

Как только это будет сделано, сделайте егоСовокупный корень будет в основном зависеть от того, считаете ли вы предприятие одной из основных точек входа в приложение, т. е. будет ли вам иногда нужна ссылка на FundTree, прежде чем даже иметь какую-либо ссылку на Фонд, или если вы можете позволить себе получить еготолько путем обхода фонда.

1 голос
/ 15 марта 2012

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

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

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

Если вы находитесь в веб-среде, это решение отличается от настольного приложения.

В Интернете вы начинаете снова каждую загрузку страницы, поэтому у меня, как правило, есть хорошая МОДЕЛЬ для сопоставления отношений и репозиторий для почти каждой сущности (поскольку мне всегда нужно сохранять лишь небольшую часть чего-либоиз какого-то всплывающего окна) и извлеките его вместе со службами, которые выполняются для совокупного корня.Это делает код предсказуемым и останавливает те ... "ммм ... это корень" моменты или репозитории, которые становятся неуправляемыми.

Тогда у меня будут мапперы, которые могут дать мне сводные и / или списочные представления.больших деревьев по мере необходимости и при необходимости.

В настольном приложении вы храните вещи в памяти намного больше, поэтому вы будете писать меньше кода, просто работая с корнями агрегата и загружая их по мере необходимости.их.

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

...