Mapeo vs. capa de servicio, o la posición lógica de negocio

Question

Tengo un producto y una colección de los pagadores. Los pagadores pueden pagar por el producto de tres maneras diferentes, ya sea de forma manual, pero establecer el porcentaje, en Fuentes de ingresos o por el valor de los respectivos pagadores holdings.How el producto se paga es determinada por una enumeración en el producto.

En mi capa de persistencia tengo tres clases, producto, Pagador, y ProductManuallyPaid que es un muchos-a-muchos de clase entre el producto y el pagador si el producto es pagado por manualmente, especificando el porcentaje que cada pagador tendrá que pagar.

¿Cómo debo asignar este a la vista? Me gustaría tener una nueva clase de muchos a muchos (que consistiría en una referencia al pagador, una referencia al producto y la cantidad exacta que debe pagar pagador)?

Creo que el cálculo debe hacerse en la capa de servicio, pero debería volver la capa de servicio una versión ViewModel / DTO del Producto / Pagador con un nuevo muchos-a-muchos de clase unida, o debería ser gestionado después? si debe ser manejado después, la entidad debe contener una lista de esa nueva clase muchos-a-muchos, pero se ignora en la capa de persistencia?

Answer 1

DDD podría sugerir que se debe adoptar una línea de pensamiento que se centra ante todo en el diseño del modelo de objetos en lugar del modelo ER / datos. Veo que has pensado en cómo el modelo de datos debe ser (con la mesa de muchos a muchos, etc), pero tal vez usted debería considerar la forma en que el modelo de objetos puede tener un aspecto en primer lugar. Luego, a medida que el modelo de objetos refleja el dominio (la lógica de negocio, el comportamiento empresarial), pensar en cómo se puede asignar ese modelo de objetos de la base de datos.

Por ejemplo, podría tener más sentido para devolver un producto que tiene una colección de Pagos. Y cada uno de pago tienen un vínculo con la entidad pagadora. Dependiendo de su diseño que enlazan Pagador puede tener copias de la información del pagador tendrá que acceder o tal vez que enlazan sabe cómo cargar la entidad Pagador completa con la información / valores necesarios. Además, cada instancia del pagador podría tener una colección de Pagos (el mismo tipo de clase que el anterior, incluso?), Que enlaza con el producto.

Este diseño hace un mejor uso de los directores OO y describe el dominio mejor que las formas A podría base de datos relacional. Además, estos objetos pueden ser más fáciles de manejar en los servicios y las capas de interfaz de usuario como su estructura objeto nativo ya que proporciona lógicamente con las cosas que necesita. es decir. Un producto tiene los pagos, que tienen el pagador, etc ..

Soy bastante nuevo a DDD pensando a mí mismo. Y antes de que el término DDD que ahuyenta a, echar un vistazo a este versión resumida de Evan libro. Es una luz leer y descargar gratis. Puede que sólo le dará las gemas que ha estado buscando.