Картирование против.уровень обслуживания или позиция бизнес-логики

Question

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

На моем уровне персистентности у меня есть три класса: Product, Payer и ProductManuallyPaid, который представляет собой класс «многие ко многим» между Product и Payer, если продукт оплачивается вручную, с указанием процента, который должен будет заплатить каждый плательщик.

Как мне сопоставить это с представлением?Я хотел бы иметь новый класс «многие-ко-многим» (который будет состоять из ссылки на Плательщика, ссылки на Продукт и точную сумму, которую плательщик должен заплатить)?

Я предполагаю, что расчет должен выполняться на уровне обслуживания, но должен ли уровень обслуживания возвращать версию ViewModel/DTO продукта/плательщика с новым прикрепленным классом «многие ко многим», или это должно быть обработано позже?если его нужно обработать позже, должен ли объект содержать список этого нового класса «Многие-ко-многим», но игнорироваться на уровне персистентности?

Answer 1

DDD может предложить вам принять образ мышления, который в первую очередь фокусируется на разработке объектной модели, а не модели ER/данных.Я вижу, вы подумали о том, как должна выглядеть модель данных (с таблицей «многие-ко-многим» и т. д.), но, возможно, вам следует сначала подумать о том, как может выглядеть объектная модель.Затем, поскольку эта объектная модель отражает предметную область (бизнес-логику, бизнес-поведение), подумайте, как можно сопоставить эту объектную модель с базой данных.

Например, может быть разумнее вернуть Продукт, у которого есть набор Платежей.И каждый платеж имеет ссылку на организацию Плательщик.В зависимости от вашего дизайна эта ссылка «Плательщик» может содержать копии информации о плательщике, к которой вы захотите получить доступ, или, возможно, эта ссылка знает, как загрузить полную сущность «Плательщик» с необходимой информацией/значениями.Кроме того, каждый экземпляр Payer может иметь набор платежей (тот же тип класса, что и выше?), которые ссылаются на Продукт.

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

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