domain driven design - driven - ¿Puede sugerir las mejores prácticas de DDD?

domain driven design aggregate root (2)

A pesar de mi comentario anterior, probé tus puntos. (Nota: no soy Eric Evans o Jimmy Nilsson, así que tome mi "consejo" con un grano de sal).

Su ejemplo "Considere un objeto que le recomienda un socio para un sitio de citas", pertenece a un servicio de dominio (no a un servicio de infraestructura). Vea este artículo aquí: http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/
Los agregados no acceden directamente a los repositorios, pero pueden crear una unidad de trabajo que combina operaciones de varios objetos de dominio en uno.
No estoy seguro de esto. Esto realmente debería ser una pregunta por sí misma.
Eso es discutible, en teoría, las entidades de dominio no estarían directamente disponibles fuera de la raíz agregada, pero eso no siempre es práctico. Considero esta decisión caso por caso.
No estoy seguro de lo que quiere decir exactamente por "consultas". Si modelar todos los escenarios posibles de "lectura" en su dominio no parece práctico o no proporciona un rendimiento suficiente, sugiere que una solución CQRS es probablemente la mejor.
Sí estoy de acuerdo. UOW es una herramienta en su caja de herramientas que puede usar en varias capas.
Esta afirmación es fundamentalmente errónea "La lógica de negocios no es una lógica de dominio". El dominio ES la lógica de negocios de representación, por lo tanto, una razón para usar ubiquitous language .

Probablemente se han formulado preguntas similares muchas veces, pero creo que cada respuesta ayuda a mejorar y comprender mejor la DDD. Me gustaría describir cómo percibo ciertos aspectos de la DDD. Tengo algunas incertidumbres básicas a su alrededor y apreciaría si alguien pudiera dar una respuesta sólida y práctica. Tenga en cuenta que estas preguntas asumen un enfoque "clásico" para DDD. Esto significa usar ORM, etc. Los enfoques como CQRS y la fuente de eventos no se consideran aquí.

Los agregados y las entidades son los objetos principales que implementan la lógica del dominio. Tienen estado e identidad. En este contexto, percibo la lógica de dominio como el conjunto de todos los comandos que mutan ese estado. ¿Tiene sentido? ¿Por qué la lógica de dominio está relacionada exclusivamente con el estado? ¿Es legal modelar objetos de dominio que no tienen identidad o ningún estado? ¿Por qué no se puede implementar un objeto de dominio como un script de transacción? Ejemplo: considere un objeto que le recomienda un socio para un sitio de citas. ¿Ese objeto no tiene un estado real, pero tiene bastante lógica de dominio? Poner eso en la capa de servicio implica que el modelo de dominio no puede cubrir toda la lógica.
Acceso a otros objetos de dominio. ¿Pueden los agregados tener acceso a un repositorio? Ejemplo: cuando un objeto de dominio (con estado) necesita tener acceso a todos los ''usuarios'' del sistema para realizar su trabajo, deberá acceder a ellos a través del repositorio. Como consecuencia, un ORM necesitaría inyectar el repositorio al cargar el objeto (lo que podría ser técnicamente más desafiante). Si los objetos no pueden acceder a los repositorios, ¿dónde ubicaría la lógica de dominio para este ejemplo? ¿En la capa de servicio? ¿No se supone que la capa de servicio no tiene lógica?
Los agregados y las entidades no deben hablar con el mundo exterior, solo les preocupa su contexto acotado. No debemos inyectar dependencias externas (como IPaymentGateway o IEmailService) en un objeto de dominio, esto causaría que el dominio maneje las excepciones que vienen de fuera. Solución: un enfoque basado en eventos. ¿Cómo se envían los eventos entonces? Aún debe inyectar los ''escuchas'' correctos cada vez que cree una instancia de un objeto de dominio. Los ORM se refieren a la restauración de "datos", pero no tienen la intención primordial de inyectar dependencias. ¿Necesitamos una mezcla DI-ORM?
Objetos de dominio y DTO''s. Cuando consulta una raíz agregada para su estado, ¿devuelve una proyección de su estado (DTO) o los objetos del dominio en sí? En la mayoría de los modelos que veo, los clientes tienen acceso total al modelo de datos del dominio, lo que introduce un acoplamiento profundo a la estructura real del dominio. Percibo que el ''gráfico de objetos'' detrás de un agregado es su propio negocio. Eso es encapsulación, ¿verdad? Así que para mí, una raíz agregada debería devolver solo los DTO. Los DTO a menudo se definen en la capa de servicio, pero mi enfoque es modelarlo en el propio dominio. La capa de servicio aún podría agregar otro nivel de abstracción, pero esa es una opción diferente. ¿Es un buen consejo?
Los repositorios manejan todas las operaciones CRUD en el nivel raíz agregado. ¿Qué pasa con otras consultas? Las consultas devuelven objetos DTO y no objetos de dominio. Para que funcione, el representante debe conocer la estructura de datos del dominio que introduce un acoplamiento. Mi consejo es similar al anterior: utilizar eventos para rellenar vistas. Por lo tanto, la estructura interna no se hace pública, solo los eventos llevan los datos necesarios para construir la vista.
Unidad de trabajo. Un controlador en el límite del sistema creará una instancia de los comandos y los pasará a una capa de servicio que, a su vez, carga los agregados apropiados y reenvía los comandos. El controlador puede usar varios comandos y pasarlos a múltiples servicios. Todo esto está controlado por la unidad de patrón de trabajo. Esto significa, repositorios, entidades, servicios, todos participan en la misma transacción. ¿Estás de acuerdo?
La lógica de negocio no es la lógica de dominio. Desde una perspectiva de negocios, la realización de un caso de uso puede implicar muchos pasos: registrar un cliente, enviar un correo electrónico, crear una cuenta de almacenamiento, etc. Este proceso general puede encajar en una raíz agregada de dominio. El objeto de dominio debería tener acceso a todo tipo de infraestructura. Solución: Flujos de trabajo o sagas (o script de transacción). ¿Es un buen consejo?

Gracias

La primera práctica recomendada que puedo sugerir es leer el libro de Evans . Dos veces
Demasiados "proyectos DDD" fallan porque los desarrolladores pretenden que DDD simplemente se hace OOP correctamente.

Entonces, realmente debe entender que DDD es para aplicaciones que tienen que manejar reglas de negocios muy complejas correctamente . En pocas palabras: si no necesita pagarle a un experto en dominios para que entienda el negocio, no necesita DDD. El concepto central de DDD, de hecho, es el lenguaje ubicuo que los programadores, los expertos y los usuarios comparten para entenderse entre sí.

Además, debe leer y comprender qué son los agregados (límites de coherencia) leyendo Diseño de agregado efectivo por Vernon .

Finalmente, puede encontrar útiles los patrones de modelado documentados aquí .