En un diseño impulsado por dominio en el que se busca un modelo de dominio no anémico, ¿cómo se decide qué implementar en los objetos de su dominio frente a los métodos orientados al servicio?¿Qué se incluye en los objetos de su modelo de dominio y qué incluye sus servicios?
EDIT: hice esta manera diferente con un ejemplo y tengo mucho mejores respuestas here
La idea de DDD es que el modelo de dominio contiene sus datos y la mayor parte de la lógica de negocio. Los servicios normalmente se ocupan de la persistencia de estas estructuras.
Luego están todos esos casos intermedios en los que el proceso comercial consiste en varios pasos que invariablemente cambian/modifican los objetos de dominio. Normalmente usas servicios para realizar algún proceso. Por lo tanto, normalmente está actualizando los objetos de dominio con los resultados de los servicios. Usted nunca ¡deje que las implementaciones de objetos de dominio llamen a los servicios por su cuenta!
así que es bastante común ver código como este:
if (order.isValidForPurchase() && orderValidatorService.isValidOrder(order))
orderService.order(order)
Simplemente porque partes de la verdad se sabe que el objeto orden, y algunos requieren datos externos que se saben orderValidatorService. Podría decirse que estas dos líneas de código también podrían estar dentro del método orderService.order.
Creo que siempre vale la pena investigar cuántos objetos de dominio existen en estos procesos: a veces se puede ganar mucho haciendo más conceptos de lo que inicialmente se pensaba. Es realmente la intersección de los estados de procesos de negocio y los modelos de objetos. Con frecuencia, los modelos DDD tienden a tratar de capturar el dominio desde una visión demasiado estructural, lo que hace que la OMI ignore demasiado los procesos centrales. Entonces, si eres demasiado estructural, creo que haces un objeto Order. Si agrega proceso, puede hacer ShoppingCartOrder, UnshippedOrder, ShippedOrder, BilledOrder y HistoricalOrder. Esto también hace que la integración de tu servicio sea más simple a veces.