¿Qué es un "modelo de dominio"?

Hola Habr

Hoy fui al canal #school en la GoCommunity en ruso en Slack y encontré un diálogo interesante allí . Este diálogo me llevó a reflexionar sobre cómo mis colegas interpretan el concepto de "modelo de dominio" .

Resultó que hay muchas interpretaciones incorrectas o poco precisas, y a veces completamente inexactas de este término, lo que esencialmente lo distorsiona. Alrededor de este diálogo, nació la idea de este artículo. Detalles debajo del corte.

Pregunta sobre arquitectura.

Entonces, el desarrollador hizo la siguiente pregunta en la comunidad:

Dígame cómo hacer la arquitectura correctamente, digamos que hice una tableta en la base de datos, solicité reformas para generar un modelo para mí, ¿puedo usar este modelo como modelo de dominio en mi aplicación, o es mejor crear mi propio modelo de dominio y hacer un adaptador que me proporcione exactamente mi modelo de dominio? ¿Creándolo a partir de un modelo de reforma?

A lo que otro programador dio la siguiente respuesta:

La más simple es la arquitectura con un modelo anémico. Esto es cuando el modelo DB = modelo de dominio = modelo de respuesta API. El modelo de dominio rico es una bestia rara y generalmente se degenera en anémica. Por anémico se entiende una estructura DTO. El conjunto habitual de atributos (campos) sin métodos. La lógica degenera en un conjunto de funciones que operan en tal dto. Fowler a veces considera que tal arquitectura es antipatrón. Pero entonces una buena solución de microservicio, etc.

Después de leer esto, de repente me di cuenta de por qué hay tanta controversia en torno a la organización de la capa de lógica de negocios, y por qué muchas personas no pueden poner en práctica enfoques tales como Arquitectura limpia , etc. ¿Qué significa "arquitectura con un modelo anémico" ?

Si intenta encontrar ese concepto en la red, lo más probable es que no lo encuentre, porque no existe tal arquitectura. Existe el concepto de "AnemicDomainModel" , y si recurrimos al mismo Fowler, resulta que este es solo un enfoque de procedimiento para crear una arquitectura de aplicación (hola Fortran, ALGOL, COBOL, BASIC, Pascal y C). Esto, en esencia, es lo que el autor de la respuesta llama "arquitectura con un modelo anémico" .

El modelo de dominio.

A continuación, surge la siguiente pregunta: ¿es el "modelo anémico" esencialmente un modelo? Creo que no, y por eso.

La verdad es que el modelo de dominio no es un modelo de datos, a diferencia del "modelo DB" o el "modelo de respuesta API" . El modelo de dominio tiene una definición muy específica . Además, es incorrecto interferir con el modelo de base de datos, que es esencialmente un modelo de datos .

Cuando se trata del modelo de dominio, este es precisamente el modelo conceptual. Y esta es la totalidad de los conceptos del área temática y las relaciones entre ellos (es decir, la totalidad del comportamiento y los datos). En general, la característica principal que distingue un modelo de un área temática de otro es precisamente un conjunto de reglas de negocio.

Sí, el modelo conceptual puede trabajar con datos que se presentan en diferentes formas (datos de la base de datos o respuestas API), pero la esencia de esto no cambiará, el comportamiento es primordial . Pasamos la entrada al modelo para obtener una salida específica. Este resultado se logra implementando la lógica de negocios dentro del modelo (en otras palabras, aplicando reglas de negocios). Aquí encuentro una analogía con modelos matemáticos y modelos de procesos tecnológicos (hola años de estudiante).

¿Qué tiene que ver con la sustitución de conceptos?

Cuando llamas a las estructuras de datos un "modelo de dominio" , eres libre o no de reemplazar conceptos. Esto lleva al hecho de que a menudo la lógica de negocios se extiende por toda la aplicación. De hecho, el modelo del área temática en este caso es el conjunto de funciones muy difuminado que opera con estructuras de datos.

En el caso de desarrollar aplicaciones medianas y grandes, un malentendido o mezcla de estos conceptos, como regla, conduce a una serie de problemas y preguntas que ya se encuentran al comienzo del desarrollo del sistema, sin mencionar el soporte a largo plazo. Entre ellos, por ejemplo, hay preguntas comunes como:

• "- ¿Dónde validar los datos?"
• "- ¿Cómo evitar las dependencias cíclicas?"
• "- ¿Es" esta "lógica de negocios en general?"
• "- ¿Y dónde guardamos la lógica comercial?"
• etc.

Además, si tiene un CRUD simple, es decir esencialmente una interfaz a la base de datos, lo más probable es que no haya problemas. Si está escribiendo una biblioteca de nivel de infraestructura (por ejemplo, para trabajar con una red o con la misma base de datos), tampoco debería haber problemas. Esto se debe a que existe un RFC y todas las "reglas comerciales" han sido claras durante mucho tiempo, y la lógica siempre ha sido clara. Puede escribir un programa de procedimiento simple, y todo estará bien de todos modos.

Si volvemos al hecho de que el diálogo sobre modelos de dominio surgió en la comunidad Go, diría que sí. Debido al hecho de que Go es un lenguaje de paradigmas múltiples y admite varios de los conceptos de OOP más exitosos (Composición, Interfaces), no los ignore al modelar un dominio y escribir código exclusivamente en un estilo de procedimiento, como si estuviera trabajando con BASIC o C.

Interpretando correctamente el concepto de "modelo de dominio", se hace bastante obvio por qué a menudo se acostumbra separar la lógica de negocios en una capa separada. También queda claro cómo puede seleccionar esta misma capa e implementar Arquitectura limpia o cualquier otra variación de la misma. Al aislar una capa separada, esencialmente creamos una biblioteca que implementa el modelo conceptual en forma de código de programa. Como resultado, la lógica de negocios se encapsula dentro del marco de esta biblioteca y no se extiende por toda la aplicación (como con un enfoque de procedimiento puro).

Por supuesto, comprender estos conceptos no lo salvará de errores de diseño, no lo convertirá en un desarrollador ideal o arquitecto de sistemas, y no le enseñará a hacer todo bien la primera vez. Aquí, no solo la teoría es importante, sino también la práctica. Sin embargo, tan pronto como comprenda correctamente los conceptos e interprete las definiciones, muchas cosas se volverán mucho más obvias y simples para usted.

Para resumir.

• No es correcto llamar a "datos" un modelo de dominio.
• Un modelo de dominio es un modelo conceptual que incluye tanto el comportamiento como los datos. Se puede encapsular en una capa separada, o se puede extender por toda la aplicación.
• "Arquitectura con un modelo anémico" no es más que un enfoque de procedimiento para crear una arquitectura de aplicación en la que el modelo de dominio se extienda por toda la aplicación

Presta atención a las definiciones, estudialas más profundamente que solo leer en diagonal. Muy a menudo somos perezosos y tomamos información en pedazos, después de lo cual se produce distorsión. No olvide volver y recoger cosas que le parecen obvias durante mucho tiempo, y siempre consulte las fuentes y llame a las cosas por su nombre.

Bueno para todos! Gracias por su atencion

PS. Estaré encantado de escuchar críticas constructivas, así como su visión de lo que es un "modelo de dominio". Las referencias a la fuente son bienvenidas.

UPD: El artículo no es un intento de interpretar libremente el concepto de "modelo de dominio" y de poner en este concepto un significado que yo sepa. Quiero transmitir esto: el significado de este concepto se ha invertido durante mucho tiempo, y se describe en detalle en libros y artículos sobre ComputerScience. El artículo es un intento de transmitir a los colegas sobre la importancia de la percepción correcta de estos mismos conceptos sin distorsionar su significado (esto es importante porque en la práctica le permitirá escribir código más significativo).

UPD2: No soy un arquitecto teórico empresarial. Soy el mismo desarrollador practicante que tú. Escribo código todos los días y hablo sobre estas cosas para mejorar mi código y hacer que los clientes estén más felices. Si, en su opinión, he distorsionado el significado original, comparto enlaces a la fuente e indique dónde lo puse incorrectamente, para que pueda solucionarlo.

UPD3: porque muchos interpretan el término "área temática" de diferentes maneras, doy algunos ejemplos de áreas temáticas para que no haya confusión ni sustitución de conceptos. El área temática siempre depende del problema que resuelva utilizando el desarrollo de aplicaciones:

• Reserva de entradas (si es desarrollador de sistemas de reservas)
• Banca (si es desarrollador de aplicaciones bancarias)
• Sistemas operativos (si es desarrollador desarrollador de SO)
• Gestión de la infraestructura de la nube (si es un desarrollador de k8s)
• Virtualización (si es un desarrollador de Docker)
• Supervisión del rendimiento (si es un desarrollador de Prometheus / Grafana)