Добавление членов объекта в бизнес-сущности в OOD

Кажется, в вашем вопросе есть предположение, что штуковина для отображения заказа должна соответствовать 1-1 с сущностью заказа.

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

Если бы у вас была таблица соединения (OrderProducts? или, еще лучше, OrderLines. Ни Order, ни Product Entities не должны были бы «знать» друг о друге. Вы могли бы сохранить их чистыми и простыми и делегировать эту функцию DisplayOrders новому объекту Join.

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

Это потребовало бы значительной переделки ваших сущностей, и если бы вы придерживались этой идеи совпадения 1-1, то и вашей БД.

Не ходи туда. Изменение — это данность. ip После комментариев...

Если это действительно отношения 1-1, то вам не нужны две сущности. 1-1 будет один продукт на заказ и один заказ на продукт.

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

Таким образом, большинство интересных методов (помимо базовой херни для двух сущностей) основаны на отношениях между двумя сущностями. Это часть предметной области, которую вы должны моделировать.

После дополнительных комментариев...

Я никогда не денормализую, если только не оптимизирую производительность, и я делаю это «в последнюю очередь», если у меня нет лучшего варианта.

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

Я бы сделал это, исходя из предположения, что свойство имени объекта издателя может измениться. Денормализация означала бы, что мне пришлось бы фиксировать изменение имени издателя, читать все книги и менять в них название. Что еще хуже, там скрыто предположение, что имя издателя уникально. Теперь вы, вероятно, могли бы пойти с этим, но во избежание действительно ужасной ошибки, если какой-то буйный пользователь даст двум издателям одно и то же имя, вам придется применить его.

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

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

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

HtHs

Это просто вопрос CQRS. Чтобы показать что-либо, связанное с пользовательским интерфейсом, просто используйте обработчик запросов (службу), получающий необходимые данные модели представления непосредственно из базы данных (постоянство), поэтому уровень Business/Domain пропускается. И это все. Вы не должны разрабатывать свою бизнес-модель на основе потребностей пользовательского интерфейса.

При изменении состояния бизнес-модели (Командная часть CQRS) дизайн должен отражать концепции и их отношения. В вашем случае Заказ ссылается на один или несколько Продуктов, используя их идентификатор. Эта модель не должна использоваться для запросов, только для создания/обновления.

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