Mapping vs. service layer, or business logic position

Question

I got a Product and a collection of Payers. The Payers can pay for the product in three different ways, either but manually set the percentage, by Payers income or by the value of the Payers respective holdings.How the product is paid is determined by an enum on the Product.

In my persistence layer i got three classes, Product, Payer, and ProductManuallyPaid which is a many-to-many class between Product and Payer if the Product is paid by manually, specifying the percentage each Payer will have to pay.

How should i map this to the view? I would like to have a new many-to-many class (which would consist of a reference to the Payer, a reference to the Product and the exact amount that payer should pay)?

I guess the calculation should be done in the Service Layer, but should the Service layer return a ViewModel/DTO version of the Product/Payer with a new many-to-many class attached, or should this be handled afterward? if it should be handled afterward, should the entity contain a list of that new Many-to-many class, but be ignored in the persistence layer?

Answer 1

DDD might suggest that you should adopt a line of thinking that focuses first and foremost on the design of the object model rather than the ER/data model. I see you have thought about how the data model should look (with the many-to-many table etc) but maybe you should consider how the object model might look first. Then as that object model reflects the domain (business logic, business behaviour), think about how you might map that object model to the database.

For example, it might make more sense to return a Product which has a collection of Payments. And each Payment have a link to the Payer entity. Depending on your design that Payer link may have copies of the Payer info you will want to access or perhaps that link knows how to load the full Payer entity with the necessary information/values. Additionally, each Payer instance might have a collection of Payments (same class type as above even?) which link back to the Product.

This design makes better use of OO principals and describes the domain better than the ways a relational database might. Additionally, these objects may be easier to handle in the Services and UI layers as their native object structure already provides you logically with the things you need. ie. a Product has the Payments, which have the Payer, etc..

I'm reasonably new to DDD thinking myself. And before the term DDD scares you off, take a look at this summarised version of Evan's book. It's a light read and free to download. It may just give you the gems you have been looking for.