Aplicar DDD a la base de datos Northwind

Question

Me gustaría hacer un ejercicio y aplicar DDD a mi modelo de dominio aplicado a la base de datos Northwind.Incluso si Northwind es un ejemplo, imagino que se hizo para satisfacer algunos requisitos de "negocios virtuales".Entonces, el objetivo es tener un modelo de dominio que respete DDD y los datos se almacenen en la base de datos Northiwnd.

Considere este modelo de persistencia de EF:

_{(fuente: desarrollarpeur.org)}

Observe que solo tenemos las entidades y las relaciones bidireccionales.Me gustaría tener un DM real que respete DDD.Además, mi modelo DM no necesita ser el espejo de mi base de datos.

1. Cómo cambiarías las relaciones para que tengan relaciones unidireccionales o bidireccionales cuando sea necesario.

2. ¿Existe alguna relación de muchos a uno o de uno a muchos que pueda cambiarse a uno a uno?

3. ¿Cómo modelarías los agregados?

4. ¿Qué tal Valores, Objetos, servicios y fábricas si es necesario?

Sé que probablemente debería analizar los requisitos comerciales y ver cómo debería cambiar el modelo, pero me gustaría recibir su consejo al respecto.

No dude en solicitar detalles si mi pregunta no está clara.

Gracias de antemano.

Answer 1

En general me siento tentado a responder Mu (en el sentido Zen) , debido a que el escenario está mal desde una perspectiva DDD. En DDD empezamos con los requerimientos del negocio y expertos de dominio y de las que se deriva una modelo de dominio .

A pesar de que es un punto de controversia, la base de datos es casi sólo un artefacto incidental de los requerimientos del negocio (que casi siempre establecen que las entidades deben persistieron).

Dicho esto, voy a tratar de hacerlo lo mejor posible.

En la mayoría de los casos, una orden es un objeto de negocio muy importante, y es obvio que necesita saber acerca de las líneas de pedido, incluyendo los productos en cada línea, por lo que parece como necesitamos la asociación de la línea de pedido (Order_Detail) a producto.

Sin embargo, cuando se les da un producto en particular, rara vez necesita saber en que los pedidos se incluyó, por lo que sugiere una relación unidireccional allí mismo. Podemos navegar desde la línea de fin de producto, pero no del producto a las líneas de pedidos.

Sin embargo, el análisis anterior puede resultar ser falsa en un nivel más profundo. Imagine la siguiente conversación entre el promotor y el experto de dominio:

Dev:. Hemos creado esta asociación de órdenes a los productos para que siempre sabemos todo sobre los productos en un orden determinado

Exp:? que suena bien, pero ¿qué pasa con el proveedor

Dev:. que se incluye, así

Exp:? Entonces, ¿qué sucede cuando se cambia el proveedor del producto

Dev: Esto se reflejará de manera implícita en los datos del pedido, así ...

Exp: Eso no es lo que queremos. Queremos que los datos que reflejan el orden en el momento que lo enviamos.

En este caso, resulta que en realidad hay un error en el esquema de base de datos. El problema puede ser causado por la presentación de informes, ya que analysists negocios pueden desear ejecutar informes sobre cómo los diferentes proveedores de ganancias impacto (lo sé).

caso de que un tipo puede sugerir el corte de la asociación de las líneas de fin de producto completo. Los pedidos deben contener datos (instantánea) de productos históricos, no de datos actualizadas.

Incluso puede entroduce un ProductSnapshot Valor de objetos que semánticamente espejos Product un Entidad para modelar esto en el modelo de dominio.

Con todo, parece más y más razonable para el modelo Order como un agregado de sí mismo y líneas de pedidos (con ProductSnapShots), pero ¿qué pasa con la relación entre pedidos y clientes?

A medida que actualmente entiendo asociaciones y agregados, asociaciones definen agregados . Dado una orden, nos gustaría saber sobre el cliente? Más probable. Teniendo en cuenta que un cliente, le gustaría saber acerca de las órdenes? Probablemente.

Esto sugiere una relación bidireccional, lo que hace Customer la Aggregate raíz . Esto significa que usted tendría una CustomerRepository, pero sin OrderRepository. Cada vez que necesite una orden, y se debe obtener a través de un Customer.

En algunos casos esto puede hacer mucho sentido, si bien esto podría ser muy torpe en otras situaciones. Realmente depende de los requerimientos del negocio ...

Se podría considerar la creación de un OrderRepository también, pero que invade el Customer agregado raíz. Si lo hace, se hace vaga Cuando la responsabilidad por las mentiras Orden. ¿Qué pasa si nagigate del orden al cliente? Customer tiene una lista de órdenes, pero todos ellos son pobladas en la memoria si se lee la Orden de la OrderRepository?

Probablemente no, pero es probable que sea si usted lee el cliente según la CustomerRepository. El punto aquí es que el análisis de Roots agregadas seimportante, y una vez que haya definido un agregado, que tendrá que seguir con ella y respetarla.

que me causas a favorecen pequeños agregados más grandes agregados, por lo que en este ejemplo, que limitaría el agregado de Order y sus líneas de pedido, y no tienen ninguna asociación entre Order y Customer.

No tener una asociación formal entre Order y Customer no significa que no podemos relacionarlos en absoluto, pero necesitamos explícitas Servicios que nos da todas las órdenes para un determinado cliente. No podemos simplemente navegar de una a la otra.