Ваша непосредственная проблема заключается в том, как перенести набор данных, который содержит некоторые данные и некоторые "несвязанные" данные, которые позволяют фильтровать эти данные далее в соответствии с моделью предметной области.
Причина, по которойпроблема заключается в том, что сама концепция переноса нескольких таблиц производных или периферийных данных на самом деле не соответствует моделированию предметной области.Моделирование предметной области - это определение отношений и сложной бизнес-логики, которые включают фундаментальные знания предметной области основного приложения.Несколько таблиц, которые не дают принципиально связанных объектов, означают, что, вероятно, это не то, что является частью модели предметной области с самого начала.
Если у вас нет объектов, которые по своей природе подходят для того, что вы пытаетесь сделатьэто означает, что либо ваша модель неполна, либо в этом случае возможно вы пытаетесь внедрить аспекты пользовательского интерфейса приложения в модель предметной области.Вероятно, последнее.
Решение состоит также в том, чтобы включить архитектуру представления пользовательского интерфейса, такую как MVP или MVC.Объекты домена предназначены для обеспечения соблюдения бизнес-правил в транзакциях - сохранения и обновления.Используйте DTO и Presenters, например, для сборки любого рода «новых» или «гибридных» объектов, которые не представляют знания основной области, а вместо этого конструируются для представления данных пользователю некоторым способом, который хочет пользователь.
В этом случае вы просто создаете DTO, который включает DTO Process и Attribute в новый объект для потребления в пользовательском интерфейсе.
Но есть и другие возможности:
1) Бывают моменты, когда вам приходится спрашивать себя, используете ли вы подходящий инструмент для работы.Я работаю над медицинским приложением, которое имеет очень сложную модель предметной области.Это основное приложение - обеспечение соблюдения сложных правил в процессе сбора данных.Но как только эти данные получены, бизнес заинтересован в том, чтобы делать с ними много разных вещей.Модель сбора данных и аналитическая модель не совсем подходят друг другу, поэтому вместо того, чтобы пытаться заставить их работать вместе, я думаю, что гораздо лучший вариант иметь модель сбора данных, которая является DDD, а затем использовать ETL и перемещать данные в хранилище данных ипредоставьте бизнесу отдельное аналитическое приложение, основанное на запросах, а не на OOP / DDD.
2) Моделирование предметной области - это определение моделей, отражающих истинную область, а не методов реляционных данных.Цель состоит в том, чтобы управлять сложностью и создать модель, которая может быть усовершенствована и изменена по мере изменения бизнеса.Вы не найдете много людей, делающих много DDD, которые даже будут притворяться, что оптимизация является одним из аспектов этого.Напротив, вы строите модель настолько последовательно, насколько это возможно, с DDD.Если вам придется позже, вы компрометируете эту модель настолько, насколько это необходимо, чтобы вывести недопустимую производительность в приемлемый диапазон.
Существует множество способов сделать запросы более эффективными.Конечно, если кто-то вообще не знает приложение, ему, возможно, придется отследить кучу всего этого, и вполне возможно, что ему придется более или менее понять все приложение, прежде чем они смогут понять все это.DDD вы можете заставить людей работать над чем-то успешно, когда они практически ничего не знают об остальной части приложения, но у вас нет ничего даже близко к оптимальному с точки зрения производительности или циклов.
Каким бы привлекательным и логичным он ни казался для лучшего из обоих миров, я занимаюсь хардкорными вещами SQL, такими как ETL и хранилище данных, а также DDD.У меня есть некоторые сомнения относительно того, насколько успешно вы можете объединить два мира в одном приложении.Вместо того, чтобы использовать лучшее из обоих миров, есть вероятность, что у вас получится приложение, с которым никто не может работать, и оно тоже не очень хорошо работает.Если у вас есть куча эффективных хранимых процедур, там обязательно будет куча бизнес-логики.Если у вас также есть «объекты», которые имеют бизнес-логику, то в итоге вы получаете бизнес-логику в базе данных, бизнес-логику в «объектной модели», которая оказывается просто (еще одним) приложением, которое имеет классы, но неООП или DDD - почти то же самое, что люди уже делают годами и называют это «n-ярусом».
Не поймите меня неправильно - приложения DDD должны по-прежнему строиться на надежных базах данных и принципах реляции, и в производительности нет ничего плохого.Но большая часть обработки на сервере БД фактически ведет к доменной активности, просочившейся в базы данных.Также многие из этих методов оптимальной обработки данных нарушают множество принципов ООП и DDD.
Если вы не желаете полностью отказаться от всего, что связано с базой данных, и это работает хорошо для вас, вам, возможно, не понадобится или даже вы не захотите перейти к концепции DDD.Если вы хотите использовать DDD, лучшим подходом является рассмотрение всего, что у вас есть, как источника ценных знаний в предметной области, но с точки зрения деталей реализации, устаревшего кода, от которого полностью отказались.DDD не очень подходит для "портирования" приложений без DDD на
.