Diseño Impulsado por Dominio: Servicio de Dominio, Servicio de Aplicación

^{(Si no tienes ganas de leer, hay un resumen en la parte inferior :-)}

Yo también he tenido problemas con la definición precisa de servicios de aplicación. Aunque la respuesta de Vijay fue muy útil para mi proceso de pensamiento hace un mes, he llegado a estar en desacuerdo con parte de ella.

Otros recursos

Hay muy poca información sobre los servicios de aplicaciones. Temas como raíces agregadas, repositorios y servicios de dominio se discuten extensamente, pero los servicios de aplicaciones solo se mencionan brevemente o se omiten por completo.

El artículo de MSDN Magazine Una Introducción al Diseño Basado en Dominios describe los servicios de aplicación como una forma de transformar y/o exponer su modelo de dominio a clientes externos, por ejemplo, como un servicio WCF. Así es como Vijay describe los servicios de aplicaciones también. Desde este punto de vista, los servicios de aplicación son una interfaz para su dominio.

Los artículos de Jeffrey Palermo sobre la cebolla Arquitectura (parte una, dos y tres) son una buena lectura. Trata los servicios de aplicación como conceptos de nivel de aplicación, como la sesión de un usuario. Aunque esto está más cerca de mi comprensión de los servicios de aplicaciones, todavía no está en línea con mis pensamientos sobre el tema.

Mis pensamientos

He llegado a pensar en los servicios de aplicación como dependencias proporcionadas por la aplicación. En este caso la aplicación podría ser una aplicación de escritorio o un servicio WCF.

Dominio

Tiempo para un ejemplo. Empiezas con tu dominio. Todas las entidades y todos los servicios de dominio que no dependen de recursos externos se implementan aquí. Cualquier concepto de dominio que dependa de recursos externos se define mediante una interfaz. Aquí hay un diseño de solución posible (nombre del proyecto en negrita):

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository

Las clases Product y ProductFactory se han implementado en el ensamblado principal. El IProductRepository es algo que probablemente es respaldado por una base de datos. La implementación de esto no es asunto del dominio y, por lo tanto, está definida por una interfaz.

, Por ahora, nos centraremos en el IExchangeRateService. La lógica de negocio de este servicio es implementada por un servicio web externo. Sin embargo, su concepto sigue siendo parte del dominio y está representado por esta interfaz.

Infraestructura

La implementación de las dependencias externas son parte de la infraestructura de la aplicación:

My Solution
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - DomainServices
      XEExchangeRateService
    SqlServerProductRepository

XEExchangeRateService implementa el servicio de dominio IExchangeRateService comunicándose con xe.com . Esta implementación puede ser utilizada por las aplicaciones que utilizan su modelo de dominio, incluyendo el ensamblaje de infraestructura.

Aplicación

Tenga en cuenta que todavía no he mencionado los servicios de aplicaciones. Los veremos ahora. Digamos que queremos proporcionar una implementación IExchangeRateService que use una caché para búsquedas rápidas. El esquema de esta clase decorador podría parecer este.

public class CachingExchangeRateService : IExchangeRateService
{
    private IExchangeRateService service;
    private ICache cache;

    public CachingExchangeRateService(IExchangeRateService service, ICache cache)
    {
        this.service = service;
        this.cache = cache;
    }

    // Implementation that utilizes the provided service and cache.
}

Observe el parámetro ICache? Este concepto no es parte de nuestro dominio, por lo que no es un servicio de dominio. Es un servicio de aplicación . Es una dependencia de nuestra infraestructura que puede ser proporcionada por la aplicación. Vamos a introducir una aplicación que demuestra esto:

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - ApplicationServices
      ICache
  - DomainServices
      CachingExchangeRateService
      XEExchangeRateService
    SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
  - ApplicationServices
      MemcachedCache
    IMyWcfService.cs
  + MyWcfService.svc
  + Web.config

Todo esto viene junto en la aplicación de esta manera:

// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);

ServiceLocator.For<IExchangeRateService>().Use(cachingService);

Resumen

Una aplicación completa consta de tres capas:

• dominio
• infraestructura
• aplicación

La capa de dominio contiene las entidades de dominio y los servicios de dominio independientes. Todos los conceptos de dominio (esto incluye servicios de dominio, pero también repositorios) que dependen de recursos externos, están definidos por interfaces.

La capa de infraestructura contiene la implementación de las interfaces desde la capa de dominio. Estas implementaciones pueden introducir nuevos dependencias no de dominio a las que se debe proporcionar la aplicación. Estos son los servicios de aplicación y están representados por interfaces.

La capa de aplicación contiene la implementación de los servicios de aplicación. La capa de aplicación también puede contener implementaciones adicionales de interfaces de dominio, si las implementaciones proporcionadas por la capa de infraestructura no son suficientes.

Aunque esta perspectiva puede no coincidir con la definición general de DDD de servicios, separa el dominio de la aplicación y le permite compartir el ensamblado de dominio (e infraestructura) entre varias aplicaciones.

El mejor recurso que me ayudó a entender la diferencia entre un Servicio de Aplicación y un Servicio de Dominio fue la implementación java del ejemplo cargo de Eric Evans, que se encuentra aquí. Si no lo carga, puede consultar el funcionamiento interno de RoutingService (un Servicio de Dominio) y BookingService, CargoInspectionService (que son Servicios de Aplicación).

Mi momento 'aha' fue desencadenado por dos cosas:

• Leyendo la descripción de los Servicios en el enlace más arriba, más precisamente esta frase:

Los servicios de dominio se expresan en términos del lenguaje ubicuo y los tipos de dominio, es decir, los argumentos del método y los valores devueltos son clases de dominio adecuadas.

• Leyendo esta entrada de blog , especialmente esta parte:

Lo que encuentro una gran ayuda para separar las manzanas de las naranjas es pensar en términos de flujo de trabajo de la aplicación. Toda la lógica relativa a la flujo de trabajo de la aplicación normalmente terminan siendo Servicios de Aplicaciones en la capa de aplicación, mientras que los conceptos del dominio que no parecen encajar como objetos modelo terminan formando uno o más Servicios de Dominio.

Domain service es la extensión del dominio. Debe ser visto solo en el contexto del dominio. Esta no es una acción de usuario como por ejemplo cerrar cuenta o algo así. El servicio de dominio se ajusta donde no hay estado. De lo contrario sería un objeto de dominio. El servicio de dominio hace algo que solo tiene sentido cuando se hace con otros colaboradores (objetos de dominio u otros servicios). Y que tener sentido es responsabilidad de otro estrato.

Application service es la capa que inicializa y supervisa la interacción entre los objetos de dominio y los servicios. El flujo es generalmente así: obtener objeto (u objetos) de dominio desde el repositorio, ejecutar una acción y ponerlo (ellos) de nuevo allí (o no). Puede hacer más-por ejemplo, puede comprobar si un objeto de dominio existe o no y lanzar excepciones en consecuencia. Por lo tanto, permite al usuario interactuar con la aplicación (y esto es probablemente donde se origina su nombre from) - manipulando objetos y servicios de dominio. Los servicios de aplicación generalmente deben representar todos los casos de uso posibles . Probablemente lo mejor que puede hacer antes de pensar en el dominio es crear interfaces de servicio de aplicaciones que le darán una idea mucho mejor de lo que realmente está tratando de hacer. Tener tal conocimiento le permite centrarse en el dominio.

Los repositorios generalmente se pueden inyectar en los servicios de dominio, pero este es un escenario bastante raro. Se es la capa de aplicación que lo hace la mayor parte del tiempo.

Del Libro Rojo (Implementing Domain Driven Design, por Vaughn Vernon), así es como entiendo los conceptos:

Objetos de dominio (entities and value objects) encapsulan el comportamiento requerido por el (sub)dominio, haciéndolo natural, expresivo y comprensible.

Los servicios de dominio encapsulan aquellos comportamientos que no caben en un objeto de dominio único. Por ejemplo, una biblioteca de libros que presta un Book a un Client (con Inventory los cambios correspondientes) pueden hacerlo desde un servicio de dominio.

Application services maneja el flujo de casos de uso, incluyendo cualquier preocupación adicional necesaria encima de del dominio. A menudo expone dichos métodos a través de su API, para el consumo de clientes externos. Para construir sobre nuestro ejemplo anterior, nuestro servicio de aplicación podría exponer un método LendBookToClient(Guid bookGuid, Guid clientGuid) que:

• Recupera el Client.
• Confirma sus permisos. (Observe cómo hemos mantenido nuestro modelo de dominio libre de preocupaciones de seguridad / administración de usuarios. Esa contaminación podría dar lugar a muchos problemas. En su lugar, cumplimos este requisito técnico aquí, en nuestro servicio de aplicaciones.)
• Recupera el Book.
• Llama al servicio de dominio (pasando el Client y Book) para manejar la lógica de dominio real de prestar el libro al cliente. Por ejemplo, imagino que confirmar la disponibilidad del libro es definitivamente parte del dominio lógica.

Un servicio de aplicación generalmente debe tener un flujo muy simple. Los flujos complejos de servicios de aplicaciones a menudo indican que la lógica de dominio se ha filtrado fuera del dominio.

Como se puede ver, el modelo de dominio se mantiene muy limpio de esta manera, y es fácil de entender y discutir con los expertos en dominios, porque solo contiene sus propias preocupaciones comerciales reales. El flujo de aplicación, por otro lado, es también mucho más fácil de administrar, ya que se libera de las preocupaciones de dominio, y se vuelve conciso y sencillo.

Servicios de dominio: Los métodos que realmente no encajan en una sola entidad o que requieren acceso al repositorio están contenidos dentro del dominio Servicio. La capa de servicio de dominio también puede contener lógica de dominio de es propio y forma parte tanto del modelo de dominio como de entidades y valores objeto.

Servicios de aplicación: El servicio de aplicación es una capa delgada que se encuentra por encima del modelo de dominio y coordina la aplicación actividad. No contiene lógica de negocio y no tiene la estado de cualquier entidad; sin embargo, puede almacenar el estado de un negocio transacción de flujo de trabajo. Utiliza un servicio de aplicación para proporcionar una API en el modelo de dominio utilizando el patrón de mensajería Solicitud-respuesta.

Millett,C (2010). Cuadro orgánico ASP.NET Patrones de Diseño. Wiley Publishing. 92.