domain-driven-design - que - domain driven design quickly

Arquitectura orientada a servicios y diseño impulsado por dominios

Question

Siempre he desarrollado el código de una manera SOA. Este año he estado tratando de hacer más DDD pero sigo sintiendo que no lo estoy obteniendo. En el trabajo nuestros sistemas tienen carga equilibrada y diseñados para no tener estado. La arquitectura es:

Sitio web

=== Capa física ==

Servicio principal

== Capa Física ==

Servidor 1 / Servicio 2 / Servicio 3 / Servicio 4

Solo el servidor 1, el servicio 2, el servicio 3 y el servicio 4 pueden comunicarse con la base de datos y el servicio principal llama al servicio correcto en función de los productos solicitados. Cada capa física tiene carga equilibrada también.

Ahora, cuando desarrollo un nuevo servicio, trato de pensar en DDD en ese servicio aunque realmente no parezca que encaja.

Uso buenos principios de DDD como entidades, tipos de valor, repositorios, agregados, fábricas y etc.

Incluso he intentado usar los ORM pero parece que no encajan en una arquitectura sin estado. Sé que hay formas de evitarlo, por ejemplo, use IStatelessSession en lugar de ISession con NHibernate. Sin embargo, ORM simplemente siente que no encajan en una arquitectura sin estado.

Me he dado cuenta de que realmente solo utilizo algunos de los conceptos y patrones que DDD me ha enseñado, pero la arquitectura general sigue siendo SOA.

Estoy empezando a pensar que DDD no encaja en sistemas grandes, pero sí creo que algunos de los patrones y conceptos encajan en sistemas grandes.

Como dije, tal vez no entiendo DDD o tal vez estoy analizando mis diseños. ¿Tal vez al usar los patrones y conceptos que DDD me enseñó a usar DDD? No estoy seguro de si realmente hay una pregunta para esta publicación, pero tengo más ideas al intentar averiguar dónde encaja el DDD en los sistemas generales y cuán escalable es realmente. La verdad es que no creo que realmente sepa qué es la DDD.

Answer 1

Creo que un error común es que SOA y DDD son dos estilos en conflicto.

En mi opinión, son dos conceptos que funcionan muy bien juntos. Crea un modelo de dominio que encapsula los conceptos de su dominio y expone puntos de entrada a ese modelo a través de los servicios.

Tampoco veo cuál es el problema con ORM y los servicios, puede usar fácilmente una sesión / uow por cada llamada de servicio. Simplemente modele sus operaciones de servicio como comandos de dominio atómico.

Un ejemplo ingenuo:

[WebMethod]
void RenameCustomer(int customerId,string newName)
{
    using(var uow = UoW.Begin())
    {
        var customerRepo = new CustomerRepo(uow);
        var customer = customerRepo.FindById(customerId);
        customer.Rename(newName);
        uow.Commit();
    }
}

Quizás el problema al que te enfrentas es que crees servicios como "UpdateOrder" que toma una entidad de pedido e intenta actualizar esto en una nueva sesión.

Intento evitar ese tipo de servicios y en su lugar los descompongo en comandos atómicos más pequeños.

Cada comando puede ser expuesto como una operación, o podría tener una sola operación de servicio que reciba grupos de comandos y luego delegarlos a los controladores de comandos.

OMI, de esta manera puedes exponer mejor tus intenciones.

Answer 2

Estoy realmente muy atrasado en esto, pero me gustaría agregar lo siguiente en las muy buenas respuestas de todos los demás.

• DDD no está en conflicto con SOA . En su lugar, DDD puede ayudarlo a mantener una mejor arquitectura orientada a servicios. SOA promueve el concepto de servicios, para que pueda definir mejores límites (¡oh, el límite de contexto también es un concepto DDD!) Entre sus sistemas y mejorar la comprensión de ellos.
• DDD no se trata de aplicar un conjunto de patrones (por ejemplo, repositorio, entidades, etc.). DDD trata principalmente de tratar de modelar su software , de modo que todos los conceptos (es decir, las clases en caso de programación orientada a objetos) se alineen directamente con los conceptos del negocio.

También debe revisar este video (especialmente los últimos 5 minutos), donde Eric Evans discute exactamente este tema.

Incluso he intentado usar los ORM pero parece que no encajan en una arquitectura sin estado.

No tengo ninguna referencia útil para respaldar esto. Sin embargo, tienes razón, los ORM no encajan bien con DDD también. Esto se debe a que están tratando de superar la falta de coincidencia entre la impedancia relacional del objeto , pero de una manera incorrecta. Forzan el software hacia un modelo de dominio anémico , donde las clases terminan siendo "titulares de datos simples".

Estoy empezando a pensar que DDD no encaja en sistemas grandes, pero sí creo que algunos de los patrones y conceptos encajan en sistemas grandes.

En el video que he vinculado arriba, también puede encontrar a Eric explicando que los conceptos de DDD pueden "romperse" en sistemas a gran escala. Por ejemplo, imagine un sistema minorista, donde cada pedido es un agregado que contiene potencialmente miles de artículos de pedido. Si desea calcular la cantidad total del pedido siguiendo estrictamente el DDD, tendrá que cargar todos los artículos del pedido en la memoria, lo que sería extremadamente ineficiente en comparación con el aprovechamiento de su sistema de almacenamiento (por ejemplo, con una declaración de SQL inteligente). Por lo tanto, esta compensación siempre debe tenerse en cuenta, DDD no es una bala de plata.

Como dije, tal vez no entiendo DDD o tal vez estoy analizando mis diseños.

Disculpe, pero tendré que citar a Eric Evans una vez más. Como él ha dicho, la DDD no es para perfeccionistas, lo que significa que puede haber casos en los que no exista el diseño ideal y que tenga que buscar una solución, que es peor en términos de modelado. Para leer más sobre eso, puedes consultar este artículo .

Answer 3

Hay algunos conceptos introducidos con DDD que realmente pueden confundirlo al crear SOA.

Tengo que estar completamente de acuerdo con otra respuesta , que los servicios SOA exponen operaciones que actúan como comandos atómicos. Creo que una SOA muy limpia usa mensajes en lugar de entidades. La implementación del servicio utilizará el modelo de dominio para ejecutar la operación.

Sin embargo, hay un concepto en DDD llamado "servicio de dominio". Esto es ligeramente diferente a un servicio de aplicación. Normalmente, un "servicio de dominio" está diseñado dentro del mismo lenguaje ubicuo que el resto del modelo de dominio, y representa una lógica de negocios que no encaja perfectamente en una entidad o valor.

Un servicio de dominio no debe confundirse con un servicio de aplicación. De hecho, un servicio de aplicación puede implementarse de manera tal que use un servicio de dominio. Después de todo, los servicios de aplicación pueden encapsular completamente el modelo de dominio dentro de SOA.

Answer 4

Las cosas más importantes sobre el diseño impulsado por dominios son las ideas generales:

• el lenguaje ubicuo,
• la toma de decisiones estratégicas en las que agrega valor trabajando en el dominio central (y aislándose de otros sistemas desagradables), y
• el enfoque para hacer diseños verificables y flexibles al desacoplar la infraestructura de la lógica empresarial.

Esos son ampliamente aplicables, y son las piezas más valiosas.

Hay muchas cosas relacionadas con los patrones de diseño de Fábricas, Servicios, Repositorios, Agregados, etc., lo tomo como un consejo de un desarrollador experimentado a otro, no como un evangelio, ya que gran parte puede variar dependiendo del idioma y los marcos. que estas usando En mi opinión, tienden a enfatizarse demasiado porque los programadores como nosotros estamos orientados a los detalles y nos obsesionamos con ese tipo de cosas. Allí también hay cosas valiosas, pero es necesario mantenerlas en perspectiva. Por lo tanto, es posible que parte de eso no sea tan relevante para usted o que crezca a medida que trabaja con él.

Por lo tanto, diría que no es como si hubiera una lista de verificación para asegurarse de que está usando todos los patrones, es una cuestión de tener en mente el panorama general y ver cómo cambia su enfoque para desarrollar software. Y si recoges algunos buenos consejos de los patrones, eso también es genial.

Específicamente con respecto a lo de SOA, he desarrollado aplicaciones que difieren todo su estado a la base de datos, que han usado objetos de dominio ignorantes de la persistencia. Escribir pruebas para los servicios que tienen que burlarse de los daos y devolver cosas es un trabajo pesado, cuanta más lógica puedo poner en los objetos del dominio, menos tengo que meterme con los simulacros en mis servicios, por lo que me gusta más ese enfoque.