design-patterns - que - modelo de dominio sin atributos
Modelo de Dominio Anémico vs. Modelo de Dominio en un diseño simple impulsado por dominio (3)
Recientemente leí una publicación en " El patrón de modelo de dominio anémico " que me llamó la atención. Mientras leía esto, descubrí que la descripción del Modelo de dominio anémico se aplicaba 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 de que el modelo de dominio fuera ligero y no muy complejo, el apodo del Modelo de Dominio Anémico 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é momento el relleno de las complejidades de su código en su capa de servicio / aplicación se convierte en incorrecto en lugar de exponer la complejidad de los objetos de su entidad? Estoy a favor de tener una propiedad "Total" en una Entidad donde internamente puede calcular el valor del Total. No soy para hacer que la Entidad se comunique directamente con otros aparatos para determinar el resultado de una de sus propiedades. Entonces, ¿es el concepto de un modelo de dominio anémico un antipatrón o una buena separación de preocupaciones? ¿Es el título Modelo de dominio anémico siempre algo malo?
Solo tengo curiosidad por saber qué pensaron los demás sobre este diseño (anti) patrón.
Dia de dia
Si coloca la lógica fuera de los objetos del dominio, pierde uno de los conceptos OO principales por completo: la encapsulación (o la ocultación de datos).
AOP lo hace hasta cierto punto, pero después de todo, uno de los principios clave de la orientación a objetos ha desaparecido.
Saludos, Stefan
La pregunta clave es preguntar por qué el modelo de dominio es anémico.
- ¿Ausencia casi total de lógica empresarial, como en una aplicación que es principalmente un conjunto de pantallas CRUD ?
- ¿Arquitectura orientada a servicios en la que los ''objetos de dominio'' son de hecho
estructuras simplesobjetos de transferencia de datos ? - ¿Consideraciones políticas o pragmáticas como la propiedad del código o la compatibilidad hacia adelante / hacia atrás que impiden excesivamente la refactorización?
- ¿Aplicando diseño de procedimiento / relacional en un lenguaje orientado a objetos?
En cualquier caso, si tuviera que elegir una regla de oro simple para el límite entre la lógica del modelo de dominio y la lógica de servicio, sería que la interacción con objetos relacionados está bien dentro del dominio, mientras se accede al "mundo exterior" (interfaz de usuario, servicios web, etc. probablemente no pertenezcan al modelo de dominio.
Si el dominio es liviano (leído: no complejo), el enfoque recomendado es usar un simple objeto de tipo ActiveRecord en su capa de dominio central. Por lo general, una asignación uno a uno entre las tablas de base de datos y los objetos de su dominio y no hay mucha "lógica" aquí. Su aplicación está simplemente mezclando registros entre la base de datos y su interfaz de usuario y permite operaciones CRUD simples.
Para dominios complejos, construiría un modelo de dominio central en el que algunos de los objetos terminen asignándose a las tablas de base de datos y otros probablemente no, y representan otros conceptos en su dominio además de datos simples. La lógica de la aplicación debe estar dentro de los objetos cuando sea apropiado o dentro de los objetos de Servicio si requiere la coordinación entre múltiples objetos de dominio.
El anti-patrón del Modelo de dominio anémico se aplica a cuando se tiene un dominio complejo, pero en lugar de poner un poco de lógica en los objetos del dominio y algo de lógica en los servicios, se pone TODA (o casi toda) la lógica externa a los objetos del dominio central.
La diferencia clave aquí es donde pones la lógica. Si no tienes mucho, obviamente los objetos de dominio se verán como simples contenedores de datos. Si tiene una lógica complicada, no solo extraiga TODOS los objetos del dominio, sino que sepárelos adecuadamente entre los objetos del dominio central y los servicios del dominio.