Diseño basado en dominio: servicio de dominio, servicio de aplicación [cerrado]
¿Alguien puede explicar la diferencia entre servicios de dominio y de aplicación proporcionando algunos ejemplos? Y, si un servicio es un servicio de dominio, ¿colocaría la implementación real de este servicio dentro del ensamblaje del dominio y, de ser así, también inyectaría repositorios en ese servicio de dominio? Alguna información sería realmente útil.
Los servicios vienen en tres tipos: servicios de dominio , servicios de aplicaciones y servicios de infraestructura .
- Servicios de dominio : encapsula la lógica empresarial que no encaja naturalmente dentro de un objeto de dominio y NO son operaciones CRUD típicas: pertenecerían a un repositorio .
- Servicios de aplicación : utilizados por consumidores externos para comunicarse con su sistema (piense en servicios web ). Si los consumidores necesitan acceso a las operaciones CRUD, estarían expuestos aquí.
- Servicios de infraestructura : se utilizan para abstraer inquietudes técnicas (por ejemplo, MSMQ, proveedor de correo electrónico, etc.).
Mantener los servicios de dominio junto con sus objetos de dominio es sensato: todos se centran en la lógica del dominio. Y sí, puedes inyectar Repositorios en tus Servicios.
Los servicios de aplicaciones normalmente utilizarán tanto servicios de dominio como repositorios para atender solicitudes externas.
(Si no tienes ganas de leer, hay un resumen al final :-)
Yo también he luchado con la definición precisa de servicios de aplicaciones. Aunque la respuesta de Vijay fue muy útil para mi proceso de pensamiento hace un mes, no estoy de acuerdo con parte de ella.
Otros recursos
Hay muy poca información sobre los servicios de aplicaciones. Se analizan ampliamente temas como raíces agregadas, repositorios y servicios de dominio, pero los servicios de aplicaciones sólo se mencionan brevemente o se omiten por completo.
El artículo de MSDN Magazine Introducción al diseño basado en dominios describe los servicios de aplicaciones 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 también describe los servicios de aplicaciones. Desde este punto de vista, los servicios de aplicaciones son una interfaz para su dominio .
Los artículos de Jeffrey Palermo sobre Onion Architecture (parte uno , dos y tres ) son una buena lectura. Trata los servicios de aplicaciones como conceptos a nivel de aplicación , como la sesión de un usuario. Aunque esto se acerca más a mi comprensión de los servicios de aplicaciones, todavía no coincide con mis pensamientos sobre el tema.
Mis pensamientos
He llegado a pensar en los servicios de aplicaciones 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
Es hora de dar un ejemplo. Comienzas con tu dominio. Aquí se implementan todas las entidades y cualquier servicio de dominio que no dependa de recursos externos. Cualquier concepto de dominio que dependa de recursos externos se define mediante una interfaz. Aquí hay un posible diseño de solución (nombre del proyecto en negrita):
Mi solución
- Mi.Product.Core (Mi.Product.dll)
- Servicios de dominio
Servicio IExchangeRate
Producto
fábrica de productos
IProductRepositorio
Las clases Producty ProductFactoryse han implementado en el ensamblaje principal. Es IProductRepositoryalgo que probablemente esté 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 empresarial de este servicio se implementa mediante 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:
Mi solución
+ Mi.Producto.Core (Mi.Producto.dll)
- Mi.Producto.Infraestructura (Mi.Producto.Infraestructura.dll)
- Servicios de dominio
Servicio XEExchangeRate
Repositorio de productos SqlServer
XEExchangeRateServiceimplementa el IExchangeRateServiceservicio de dominio comunicándose con xe.com . Esta implementación puede ser utilizada por sus aplicaciones que utilizan su modelo de dominio, al incluir el ensamblaje de infraestructura.
Solicitud
Tenga en cuenta que todavía no he mencionado los servicios de aplicaciones. Los veremos ahora. Digamos que queremos proporcionar una IExchangeRateServiceimplementación que utilice un caché para búsquedas rápidas. El esquema de esta clase de decorador podría verse así.
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.
}
¿Notas el ICacheparámetro? Este concepto no forma 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. Introduzcamos una aplicación que demuestra esto:
Mi solución
- Mi.Product.Core (Mi.Product.dll)
- Servicios de dominio
Servicio IExchangeRate
Producto
fábrica de productos
IProductRepositorio
- Mi.Producto.Infraestructura (Mi.Producto.Infraestructura.dll)
- Servicios de aplicaciones
ICache
- Servicios de dominio
Servicio de tasa de intercambio de almacenamiento en caché
Servicio XEExchangeRate
Repositorio de productos SqlServer
- Mi.Product.WcfService (Mi.Product.WcfService.dll)
- Servicios de aplicaciones
MemcachedCaché
IMyWcfService.cs
+ MiWcfService.svc
+ Web.config
Todo esto se reúne 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 principales:
- dominio
- infraestructura
- solicitud
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 se definen mediante interfaces.
La capa de infraestructura contiene la implementación de las interfaces de la capa de dominio. Estas implementaciones pueden introducir nuevas dependencias fuera del dominio que deben proporcionarse a la aplicación. Estos son los servicios de la aplicación y están representados por interfaces.
La capa de aplicación contiene la implementación de los servicios de la 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 servicios de DDD, separa el dominio de la aplicación y le permite compartir el ensamblaje del dominio (y la infraestructura) entre varias aplicaciones.
El mejor recurso que me ayudó a comprender la diferencia entre un servicio de aplicación y un servicio de dominio fue la implementación en Java del ejemplo de carga de Eric Evans, que se encuentra aquí . Si lo descarga, puede consultar los aspectos internos de RoutingService (un servicio de dominio) y BookingService, CargoInspectionService (que son servicios de aplicación).
Mi momento de 'ajá' fue provocado por dos cosas:
- Leyendo la descripción de los Servicios en el enlace de 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 de retorno son clases de dominio adecuadas.
- Leyendo esta publicación de blog , especialmente esta parte:
Lo que encuentro de gran ayuda a la hora de separar las manzanas de las naranjas es pensar en términos del flujo de trabajo de la aplicación. Toda la lógica relacionada con el flujo de trabajo de la aplicación normalmente termina siendo Servicios de Aplicación incluidos 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.
Del Libro Rojo (Implementación del diseño basado en dominios, de Vaughn Vernon), así es como entiendo los conceptos:
Los objetos de dominio ( entidades y objetos de valor ) encapsulan el comportamiento requerido por el (sub)dominio, haciéndolo natural, expresivo y comprensible.
Los servicios de dominio encapsulan comportamientos que no caben en un único objeto de dominio. Por ejemplo, una biblioteca de libros que presta un libro Booka un Client(con Inventorylos cambios correspondientes) podría hacerlo desde un servicio de dominio.
Los servicios de aplicaciones manejan el flujo de casos de uso, incluidas cualquier inquietud adicional necesaria además de la del dominio. A menudo expone dichos métodos a través de su API, para que los consuman clientes externos. Para aprovechar 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 problemas de seguridad/gestión de usuarios. Tal contaminación podría provocar muchos problemas. En cambio, cumplimos con este requisito técnico aquí, en nuestro servicio de aplicaciones) .
- Recupera el
Book. - Llama al servicio de dominio (pasando
ClientyBook) para manejar la lógica del dominio real de prestar el libro al cliente. Por ejemplo, imagino que confirmar la disponibilidad del libro es definitivamente parte de la lógica del dominio.
Un servicio de aplicación generalmente debería tener un flujo muy simple. Los flujos de servicios de aplicaciones complejos a menudo indican que la lógica del dominio se ha filtrado fuera del dominio.
Como 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 el dominio, porque solo contiene sus propias preocupaciones comerciales reales. El flujo de aplicaciones , por otro lado, también es mucho más fácil de gestionar, ya que se eliminan las preocupaciones de dominio y se vuelve conciso y sencillo.
