Сопоставление между уровнем обслуживания или уровнем бизнес-логики - PullRequest
Новая
       46

Сопоставление между уровнем обслуживания или уровнем бизнес-логики

1 голос
/ 01 декабря 2009

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

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

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

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

1 Ответ

3 голосов
/ 12 декабря 2009

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

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

Этот дизайн лучше использует принципы ОО и описывает домен лучше, чем способы, которыми могла бы заниматься реляционная база данных. Кроме того, эти объекты могут быть проще обрабатывать в слоях Services и UI, поскольку их собственная структура объектов уже предоставляет вам необходимые вещи. то есть. Товар имеет Платежи, которые есть у Плательщика и т. д.

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

...