7

Tengo una configuración estándar de Order/OrderLineItem.DDD/DI (Unity)/.NET/Composition Root - Domain Services

Se generan varios reembolsos durante el día que se mantienen durante el día, el reembolso consiste en un Id. De pedido y 1 o más Id de elemento de línea. Necesito consolidar estos (en un servicio de Windows) al final del día, el reembolso a tarjetas de crédito, tarjetas de regalo, tarjetas de recompensas, etc., según corresponda.

He estado leyendo Mark Seemann's book y puedo ver el beneficio de usar un Composition Root para crear un gráfico de objetos.

El proceso de consolidación en sí es donde tengo que hacer la mayor parte de la composición.

Lo que no entiendo es exactamente donde debe terminar esta lógica de consolidación? ¿Puedo suponer que independientemente de dónde termine la lógica de consolidación, todavía utilizo algo como Unity en la raíz de la composición y esa composición debería ocurrir muy temprano?

¡Feliz de proporcionar más información o aclarar según corresponda!

Respuesta

3

El proceso de consolidación en sí es donde tengo que hacer la mayor parte de la composición.

Entonces, ¿quiere decir que el proceso de creación de datos en su sistema es donde se crearán la mayoría de los objetos de dominio?

Eso tiene sentido, y está en línea con la mayoría de las aplicaciones.

Lo que no entiendo es exactamente dónde debe terminar esta lógica de consolidación?

La lógica de consolidación estará a cargo de uno o más componentes de servicio, es probable que utiliza uno o más componentes repository y uno o más componentes unit of work. Ese servicio estará compuesto en la raíz de la composición, al igual que cualquier repositorio/unidades de trabajo que termine creando.

Los datos en sí son completamente dinámicos. No puede estructurar su aplicación para conocer el diseño de los datos de forma estática, por lo que no puede componerla en la raíz de su composición. Tampoco deberías intentarlo.En su lugar, su código podría usar un ORM para definir o asignar al esquema relacional entre los objetos de datos de su dominio.

Luego puede usar el repositorio/unidad de trabajo para recuperar datos del almacenamiento. También usa su UI/servicio para crear nuevos datos usando new - no hay vergüenza en eso para objetos de dominio que son puramente datos, y se garantiza que no tienen dependencias. Persista los datos nuevos o modificados en el repositorio/unidad de trabajo.

Si esto lo hace temblar, siempre puede usar un patrón de fábrica que se inyecta desde la raíz de la composición para crear esos objetos. Pero si ha estructurado sus objetos de dominio de bajo nivel para que sean DTOs, esto no le comprará mucho, en todo caso.

Así que no tiene que usar Unity para proporcionar todo, y no tiene que crear absolutamente todos los objetos de su sistema en la raíz de la composición. Pero debe tratar de componer piezas estáticas de su sistema, o incluso piezas dinámicas configurables estáticamente de su sistema en la raíz de la composición. Esto se asigna muy bien a contenedores DI como Unity.

+0

Gracias por su respuesta. Tengo una pregunta basada en lo que ha dicho antes ... ¿Debería utilizar siempre un servicio de llamada que a su vez utiliza un repositorio en lugar de utilizar cualquier repositorio directamente? – inthegarden

+0

@inthegarden: no puede exponer repositorios directamente en la máscara de un servicio y no puede devolver entidades directamente a la interfaz de usuario. Entonces, en el nivel superior de tu aplicación vas a necesitar * algún tipo de capa. Si esto se asigna por completo a una capa de servicio externo, eso es genial. Pero no insertaría todos los enganches de servicio en todo en esa capa * a menos que * quisiera exponer cada pieza de funcionalidad que está en la interfaz de usuario a las personas que llaman a un servicio web. El servicio es un conjunto separado de requisitos de la interfaz de usuario, por lo que no se exagere al hacer que todo pase por ello. –

3

En caso de que sus artículos de reembolso sean solo contenedores de datos o entidades que no tengan ninguna dependencia de los servicios, simplemente puede crear una instancia utilizando new.

Si tienen dependencias y deben ser creadas por su contenedor de IoC y no pueden hacerlo al inicio, querrán usar una interfaz de fábrica. Esta interfaz de fábrica contiene un método CreateRefund que toma todos los parámetros requeridos que desea pasar a la instancia creada. Esta interfaz se define en el espacio de nombres/conjunto de su consumidor.

La implementación de esta interfaz depende del contenedor IoC. Algunos contenedores proporcionan la funcionalidad de que el contenedor implemente automáticamente la interfaz con solo especificarla en la configuración. Otros como Unity requieren una implementación manual. Esta implementación reside en Composition Root como parte de la configuración de su contenedor. Deje que la implementación tome una instancia del contenedor y úselo para crear la instancia de Reembolso solicitada.

De esta manera, el único lugar donde accede al contenedor está en la raíz de composición.