ADM es un buen patrón para una solución de servicios distribuidos como microservicios. Se adapta a muchos de los casos comerciales actuales basados en la web.
Considere si tenemos un objeto Order Domain. Con un enfoque OOP, agregaríamos Order.Purchase () Order.Cancel (), etc. Funcionaría bien en una aplicación de escritorio, donde guardamos pedidos en la memoria y hacemos varias cosas en la misma instancia.
Pero si tenemos un sistema distribuido, con programas que solo tienen una cosa, es decir, acceder a una lista de pedidos y comprar cada uno por turno, u obtener una lista de pedidos y cancelarlos por turno, entonces tener ambos métodos en el mismo objeto no hace sentido. Tendríamos que tener dos dominios o contextos limitados:
PurchaseSystemOrder.Purchase()
y
CancelSystemOrder.Cancel();
Lo único que compartirían estos objetos sería la estructura de datos de las propiedades.
A medida que agrega más y más microservicios, termina con docenas de tipos de Orden. Ya no tiene sentido hablar de una Orden como un objeto de Dominio, a pesar de que es el mismo orden conceptual que están procesando todos estos sistemas.
Tiene mucho más sentido tener un modelo anémico, Order, que encapsula solo los datos y cambia el nombre de sus servicios en consecuencia:
PurchaseService.Purchase(Order order)
Ahora podemos hablar sobre Order nuevamente y podemos agregar cualquier servicio nuevo que pensemos para procesar, sin afectar los otros servicios implementados actualmente.
Fowler y Co provienen de un entorno de sistema monolítico, en su mundo, un enfoque ADM significaría una sola aplicación con todos estos servicios separados instanciados en la memoria y el OrderDTO se pasa y muta. Esto sería mucho peor que poner los métodos en un modelo de Orden rico.
Pero en un sistema distribuido, hay muchos programas, cada uno solo requiere un único método de Pedido y lo ejecuta en múltiples pedidos, carga cada uno, ejecuta el método y luego lo descarta. Solo requiere un único Servicio y una secuencia de objetos de datos.
Rellenar un modelo rico por completo, preocuparse por los requisitos y dependencias de todos los métodos solo para llamar a uno solo y luego descartar el objeto casi de inmediato no tiene sentido.
Además, un cambio a uno solo de los métodos requeriría actualizar todos los componentes distribuidos, ya que todos dependen del Modelo Rico para su lógica.
No tengo espacio en mi (s) base (s) de código para cosas que no necesitan