DDD: организация сотен свойств на объекте

Question

Как бы вы организовали объект с сотнями свойств? Можно пойти так далеко, чтобы сказать сотни свойств, с несколькими объектами значения (так как некоторые свойства имеют 2 или 3 собственных свойства). Но дело в том, как обрабатывать большое количество свойств.

Я воссоздаю нашу модель с нуля, используя DDD, и текущая проблема заключается в том, как организовать одну из основных сущностей, которая разбита на множество, множество подмножеств. В настоящее время написано, что у него около десятка подмножеств свойств. Например, CarInfo () с 50+ свойствами, CarRankings () с 80+, CarStats (), CarColor () и т. Д. И т. Д.

Думайте об этом как о массовых данных, хранящихся в одном корне сущности.

Уместно ли иметь службу для простой цели группировки большой коллекции свойств? Как и CarInfoService, которая возвращает объект Car () вместе с большой коллекцией или сортировкой.

Другой идеей было бы посмотреть, как отображаются данные. Нет ни одного представления, которое показывает все эти данные. Вместо этого они разделены на основе их субъективного вопроса. Лайк CarInfo показывает всю информацию об автомобиле. Другой будет CarStats, который показывает все характеристики автомобиля. Таким образом, в этом смысле прикладной уровень может создавать базовые детали, необходимые для пользовательского интерфейса. Но мне все еще нужен способ сохранить его в домене.

У меня есть желание просто положить несколько сумок с XML-свойствами и позвонить в тот же день. лол

Answer 1

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

Таким образом, в случае более глубокого понимания, есть вероятность, что вам придется реорганизовать только BC, не затрагивая другие.

Answer 2

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

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

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

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

Если вам нужно собрать полный root со всеми его ветвями, я думаю, вам определенно понадобится какой-то сервис, который соберет все вместе.