Arquitectura Orientada a Servicios y Diseño Dirigido por Dominio

Question

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

sitio web

=== == capa física

Servicio Principal

== == capa física

Servidor 1/2 Servicio/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 también está balanceada.

Ahora cuando desarrollo un nuevo servicio, trato de pensar en DDD en ese servicio, aunque realmente no me parece que encaje.

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

Incluso he intentado utilizar ORM pero simplemente no se parecen como encajan en una arquitectura sin estado. Sé que hay formas de evitarlo, por ejemplo, usar 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 uso 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 cabe en sistemas grandes, pero creo que algunos de los patrones y conceptos encajan en sistemas grandes.

Como dije, ¿tal vez no estoy captando DDD o quizás estoy analizando mis diseños? Quizás al usar los patrones y conceptos que DDD me ha enseñado, ¿estoy usando DDD? No estoy seguro de si realmente hay una pregunta para esta publicación, sino más ideas que he tenido al tratar de descubrir dónde encaja DDD en los sistemas en general y cuán escalable es realmente. La verdad es que no creo que realmente sepa qué es DDD.

Answer 1

Las cosas más importantes sobre Driven Design-Domain son las ideas de imagen:

• el lenguaje ubicuo,
• la toma de decisiones estratégicas, donde va a agregar valor trabajando en el dominio del núcleo (y aislándose de otros sistemas desagradables) y
• el enfoque para hacer diseños comprobables y flexibles desacoplando la infraestructura de la lógica comercial.

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

Hay un montón de cosas de patrones de diseño sobre 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 de el lenguaje y los marcos que estás usando. en el sentido de que tienden a sobreestimarse porque los programadores como nosotros están orientados a los detalles y nos obsesionamos con ese tipo de cosas. También hay cosas valiosas, pero debe mantenerse en perspectiva.Por lo tanto, es posible que alguno de ellos no sea relevante para usted, o podría crecer en usted a medida que trabaja con él.

Así que yo diría que no es que haya una lista de verificación que pueda ejecutar para asegurarse de que está usando todos los patrones, se trata de tener en cuenta el panorama general y ver cómo eso 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 en la base de datos, que han utilizado objetos de dominio que ignoran la persistencia. Escribir pruebas para servicios que tienen que burlarse de daos y retroalimentar cosas es un trabajo pesado, mientras más lógica pueda poner en los objetos de dominio, menos tendré que meterme con los simulacros en mis servicios, así que me gusta más ese enfoque.

Answer 2

Creo que una idea errónea común es que SOA y DDD son dos estilos contradictorios.

IMO, 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 en ese modelo a través de servicios.

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

un ejemplo ingenua:

[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(); 
    } 
} 

Tal vez el problema que se enfrentan es que permite crear servicios como "UpdateOrder", que tiene una entidad para e intenta actualizar esta en una nueva sesión?

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

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

IMO, de esta manera puede exponer mejor sus intenciones.

Answer 3

Existen algunos conceptos que se introducen con DDD que realmente pueden confundirte al construir SOA.

Tengo que estar totalmente de acuerdo con another answer, que los servicios SOA exponen las 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 denominado "servicio de dominio". Esto es ligeramente diferente a un servicio de aplicación. Típicamente, 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 limpiamente en una entidad o valor.

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