modelo de dominio anémico frente a modelo de dominio en un diseño de dominio simple

Question

Recientemente leí una publicación en "The Anemic Domain Model Pattern" que me llamó la atención. Al leer esto, descubrí que la descripción del Modelo de Dominio Anemico se aplica a muchos de los proyectos en los que he trabajado y construido. Nunca pensé en esto como una mala decisión de diseño, ya que se sentía muy natural. Pensé que en el caso donde el domain model era liviano y no muy complejo, el apodo de Anemic Domain Model encajaba bastante bien. ¿Por qué agregar complejidad al modelo de dominio donde no tiene que ser solo para que el título de "Modelo de dominio anémico" no describa adecuadamente su código?

Pregunta: ¿En qué punto el relleno de más complejidades de código en su capa de servicio/aplicación se vuelve incorrecto en lugar de exponer la complejidad de los objetos de su entidad en su lugar? Estoy a favor de tener una propiedad "total" en una entidad donde internamente pueda calcular el valor del total. No estoy para hacer que la Entidad se comunique directamente con varios otros widgets para determinar el resultado de una de sus propiedades. Entonces, ¿el concepto de un Modelo de Dominio Anemico es un antipatrón o una buena separación de preocupaciones? ¿Es el título Anemic Domain Model siempre algo malo?

Recién curioso de lo que otras personas pensaban sobre este patrón de diseño (anti).

Answer 1

La cuestión clave es preguntar por qué es el modelo de dominio anémico?

• casi total ausencia de lógica de negocio, como en una aplicación que es principalmente un conjunto de CRUD screens?
• Arquitectura orientada a servicios en la que los 'objetos de dominio' son de hecho estructuras simples data transfer objects?
• ¿Consideraciones políticas o pragmáticas como la propiedad del código o la compatibilidad con versiones anteriores o posteriores que impiden excesivamente la refactorización?
• ¿Aplica el diseño procedural/relacional en un lenguaje orientado a objetos?

En cualquier caso, si tuviera que elegir una regla básica para el límite entre lógica de modelo de dominio y lógica de servicio, sería que interactuar con objetos relacionados está bien dentro del dominio, mientras se accede al "exterior world "(interfaz de usuario, servicios web, etc.) probablemente no pertenezca al modelo de dominio.

Answer 2

Si el dominio es liviano (léase: no es complejo), el enfoque recomendado es utilizar objetos simples de tipo ActiveRecord en la capa de dominio central. Por lo general, un mapeo uno a uno entre las tablas de BD y los objetos de su dominio y aquí no hay mucha "lógica". Su aplicación simplemente está mezclando registros entre la base de datos y su UI y permitiendo operaciones simples de CRUD.

Para dominios complejos, crearía un modelo de dominio central donde algunos de los objetos terminan mapeándose en tablas de BD y otros probablemente no y representen otros conceptos en su dominio además de solo datos simples. La lógica para la aplicación debe estar dentro de los objetos cuando corresponda o dentro de los objetos de servicio si requiere la coordinación entre múltiples objetos de dominio.

El antipatrón de Anemic Domain Model se aplica cuando tiene un dominio complejo pero en lugar de poner algo de lógica en los objetos de dominio y cierta lógica en servicios, pone TODA (o casi toda) la lógica externa a su núcleo objetos de dominio.

La diferencia clave aquí es donde pones la lógica. Si no tiene mucho, obviamente los objetos de dominio se verán como nada más que simples contenedores de datos. Si tiene una lógica complicada, no solo extraiga TODO de los objetos de dominio, sino más bien sepárela de forma adecuada entre los objetos de dominio principal y los servicios de dominio.

Answer 3

G'day!

Si coloca la lógica fuera de los objetos de dominio, pierde por completo uno de los conceptos principales de OO: encapsulación (u ocultación de datos).

AOP lo hace hasta cierto punto, pero después de todo, uno de los aspectos más importantes de la orientación a objetos ha desaparecido.

Saludos, Stefan