Según el libro Domain-Driven Design de Eric Evans los conceptos clave son lenguaje ubicuo, contexto delimitado y el aislamiento entre contextos, junto con elementos de diseño como Entidad, Value Object y Servicio. La pregunta sobre si es aceptable poner la lógica de negocio dentro de un Servicio en lugar de en una Entidad y aceptar que la Entidad quede anémica pero siga conservando identidad, contexto y lenguaje ubicuo es habitual en proyectos reales.
Un modelo de dominio anémico se caracteriza por entidades que solo contienen datos y servicios que contienen la lógica. Evans y muchos defensores de DDD consideran esto una anti pauta porque dificulta expresar las invariantes y el comportamiento del dominio allí donde pertenecen. Sin embargo, no siempre es un error mortal: hay casos legítimos para usar Servicios de dominio cuando la operación no tiene un hogar natural en una sola Entidad o Aggregate.
Cuándo es aceptable colocar lógica en Servicios: cuando la operación coordina varias entidades o agregados, cuando implementa reglas que cruzan límites transaccionales, cuando se trata de lógica de integración con sistemas externos, o cuando la responsabilidad es claramente de aplicación y no de dominio puro. Los Servicios de aplicación pueden orquestar llamadas a entidades y repositorios sin contener reglas de negocio profundas; los Servicios de dominio encapsulan operaciones relevantes al ubiquity language pero que no encajan en una sola entidad.
Buenas prácticas y recomendaciones: conservar invariantes críticas y comportamiento que definen la identidad dentro del Aggregate Root; modelar conceptos inmutuables como Value Objects; usar Domain Services solo para operaciones puramente del dominio que no pertenecen a una entidad concreta; mantener Application Services finos para orquestación, transacciones y autorización; preservar el lenguaje ubicuo en nombres de métodos y clases; y definir límites claros entre bounded contexts para evitar contaminación de responsabilidades.
Aspectos prácticos: en arquitecturas orientadas a performance, CQRS o microservicios, es común tener modelos de lectura anémicos y modelos de escritura ricos. Desplegar lógica en servicios puede facilitar pruebas unitarias y escalado, pero también puede dispersar reglas y hacer más difícil mantener la coherencia del dominio si no se aplican límites claros.
En resumen, es aceptable diseñar cierta lógica en Servicios si se hace conscientemente y respetando las reglas del dominio: mantener las invariantes dentro de los agregados, preservar la identidad de las entidades y conservar el lenguaje ubicuo y los límites de contexto. Si la Entidad sigue siendo parte del producto, del contexto y del lenguaje ubicuo, el concepto central de DDD puede mantenerse, aunque conviene auditar y refactorizar cuando la dispersión de lógica comprometa la claridad o la integridad del dominio.
En Q2BSTUDIO ayudamos a tomar estas decisiones arquitectónicas y a implementarlas en soluciones reales. Somos especialistas en desarrollo de software a medida y aplicaciones a medida, además de inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Si necesitas diseñar correctamente tus modelos de dominio o construir una solución con software a medida consulta nuestras opciones de desarrollo de aplicaciones multiplataforma y para proyectos con machine learning y agentes IA visita nuestros servicios de inteligencia artificial. Contáctanos para evaluar compromiso entre pureza del dominio y necesidades prácticas del negocio.