Настройка модели проектирования на основе домена - PullRequest
0 голосов
/ 03 марта 2019

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

Цель моего приложения - создать набор XML-файлов, называемых «компонентами».Все построенные «компоненты» образуют общую «сборку».Каждый компонент содержит целый набор атрибутов, таких как аргументы, сводки и т. Д.

До сих пор я решил, что атрибуты «компонентов» будут объектами значения, а сам «компонент» будет сущностью (так как у него есть время жизни в приложении).Я также полагаю, что «сборка» в целом должна быть сущностью, поскольку время ее существования будет временем, в течение которого компоненты создаются и создаются, и т. Д.(или) корень (и) быть?Должен ли «компонент» быть Агрегатом, потому что они часто рассматриваются как единое целое с точки зрения их конструкции?Но тогда сборка также должна быть Агрегатом, который содержит список связанных Агрегатов (то есть «компонентов»), это нормально?

Будем весьма признательны за любые указания или материалы по этому вопросу!

1 Ответ

0 голосов
/ 05 марта 2019

Цель моего приложения - создать набор XML-файлов, называемых «компонентами»

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

...