design-patterns – Enfoque DDD para operaciones CRUD básicas en una aplicación compleja centrada en el dominio

Pregunta:

Mi empresa está reescribiendo nuestra aplicación web desde cero. Es una aplicación de nivel empresarial grande con un dominio complejo en la industria financiera.

Estamos usando un ORM (Entity framework) para la persistencia.

En esencia, la mitad de nuestra aplicación se centra en recopilar datos sin procesar del usuario, almacenarlos, y luego la otra mitad de la aplicación que contiene la mayor parte de nuestra lógica de dominio real toma esos datos sin procesar para crear nuestra imagen de dominio que difiere mucho de los originales. entradas sin procesar, y lo pasa a un motor de cálculo, ejecuta cálculos y arroja resultados, que luego se muestran al usuario.

En un enfoque DDD que usa capas, parece que las operaciones CRUD pasan por la capa de dominio. pero al menos en nuestro caso, esto no parece tener sentido.

Cuando un usuario va a la pantalla de edición para cambiar una cuenta de inversión, por ejemplo, los campos en la pantalla son los campos exactos almacenados en la base de datos, no la representación del dominio utilizada posteriormente para los cálculos. Entonces, ¿por qué debería cargar la representación del dominio de la cuenta de inversión cuando la pantalla de edición necesita la representación de la base de datos (entradas sin procesar)?

Después de que el usuario haga clic en "Listo" en la pantalla de la cuenta de inversión y se realice un POST al controlador, el controlador ahora tiene una representación de base de datos prácticamente exacta de la cuenta de inversión que necesita guardar. Pero, por alguna razón, se supone que debo cargar la representación del dominio para realizar modificaciones en lugar de simplemente asignar el modelo del controlador directamente al modelo de la base de datos (modelo de marco de entidad).

Entonces, en esencia, estoy mapeando un modelo de datos al modelo de dominio, solo para que luego se pueda mapear de nuevo al modelo de datos para que persista. ¿Cómo eso tiene sentido?

Respuesta:

¿Cómo eso tiene sentido?

Respuesta corta: no lo hace .

Respuesta más larga: los patrones pesados ​​para desarrollar un modelo de dominio no se aplican a aquellas partes de su solución que son solo una base de datos.

Udi Dahan tuvo una observación interesante que puede ayudar a aclarar esto

Dahan considera que un servicio debe tener algún tipo de funcionalidad y algunos datos. Si no tiene datos, entonces es solo una función. Si todo lo que hace es realizar operaciones CRUD en los datos, entonces es una base de datos.

Después de todo, el objetivo del modelo de dominio es garantizar que todas las actualizaciones de los datos mantengan el negocio actual invariable. O dicho de otro modo, el modelo de dominio se encarga de que la base de datos que actúa como sistema de registro sea ​​la correcta.

Cuando se trata de un sistema CRUD, por lo general no es el sistema de registro de los datos. El mundo real es el libro de registro, y su base de datos es solo una representación en caché local del mundo real.

Por ejemplo, la mayor parte de la información que aparece en un perfil de usuario, como una dirección de correo electrónico o un número de identificación emitido por el gobierno, tiene una fuente de verdad que se encuentra fuera de su empresa: es el administrador de correo de otra persona el que asigna y revoca las direcciones de correo electrónico, no tu aplicación Es el gobierno el que asigna los SSN, no su aplicación.

Por lo tanto, normalmente no realizará ninguna validación de dominio en los datos que le llegan del mundo exterior; es posible que tenga controles para asegurarse de que los datos estén bien formados y debidamente desinfectados ; pero no son sus datos: su modelo de dominio no tiene veto.

En un enfoque DDD que usa capas, parece que las operaciones CRUD pasan por la capa de dominio. pero al menos en nuestro caso, esto no parece tener sentido.

Eso es correcto para el caso en que la base de datos es el libro de registro .

Ouarzy lo expresó de esta manera .

Sin embargo, al trabajar en una gran cantidad de código heredado, observo errores comunes para identificar qué hay dentro del dominio y qué hay fuera.

Una aplicación puede considerarse CRUD solo si no existe una lógica comercial en torno al modelo de datos. Incluso en este (raro) caso, su modelo de datos no es su modelo de dominio. Simplemente significa que, como no hay lógica comercial involucrada, no necesitamos ninguna abstracción para administrarlo y, por lo tanto, no tenemos un modelo de dominio.

Usamos el modelo de dominio para administrar los datos que pertenecen dentro del dominio; los datos de fuera del dominio ya se administran en otro lugar; solo estamos almacenando en caché una copia.

Greg Young utiliza los sistemas de almacén como una ilustración principal de las soluciones en las que el libro de registro está en otro lugar (es decir, el piso del almacén). La implementación que describe es muy parecida a la suya: una base de datos lógica para capturar los mensajes recibidos del almacén y luego una base de datos lógica separada que almacena en caché las conclusiones extraídas del análisis de esos mensajes.

Entonces, ¿tal vez tenemos dos contextos acotados aquí? Cada uno con un modelo diferente para una investment account

Quizás. Sería reacio a etiquetarlo como un contexto acotado, porque no está claro qué otro equipaje lo acompaña. Puede ser que tenga dos contextos, puede ser un contexto con diferencias sutiles en el lenguaje omnipresente que aún no ha captado.

Posible prueba de fuego: cuántos expertos de dominio necesita; dos expertos en el dominio para cubrir este espectro, o solo uno que habla sobre los componentes de diferentes maneras? Básicamente, es posible que pueda adivinar cuántos contextos acotados tiene trabajando la ley de Conway al revés.

Si considera que los contextos limitados están alineados con los servicios, puede ser más fácil: ¿debería poder implementar estas dos funciones de forma independiente? Sí sugiere dos contextos acotados; pero si necesitan mantenerse sincronizados, entonces tal vez sea solo uno.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım