He estado trabajando en una aplicación relativamente compleja con 10 de tablas de bases de datos (agregados, entidades / objetos de valor) y aplicando DDD. En este punto, parece ser básicamente DDD-Lite, lo que significa que hay servicios de aplicación / dominio, el modelo de dominio (entidades, objetos de valor) y repositorios.
Recogí un libro Implementando DDD y lo primero que está mencionando es que DDD-Lite y los Contextos delimitados y los Eventos de dominio faltan como primeros errores que son habituales al comenzar DDD.
Actualmente he intentado organizar las relaciones Modelo de dominio por agregado y usar espacios de nombres para demostrarlo.
No puedo ver los beneficios / caídas relacionadas con la separación del proyecto Modelo de dominio en contextos limitados separados (todavía). Tal vez se hará evidente más adelante, pero me gustaría recibir comentarios de la vida real sobre los contextos limitados (y posiblemente subdominios, etc., si se relacionan).
Respuestas:
Considere una empresa que tiene algunos departamentos diferentes:
¿Se te ocurre un modelo de usuario que pueda representar expresamente todas esas áreas de negocio? Piense en cómo se vería la entidad Usuario en cada una. Quizás se divide en tres entidades diferentes:
El esfuerzo para crear una instancia de un usuario en cada contexto es considerablemente diferente. Quizás sea algo como esto:
disculpe el ejemplo, es difícil de ilustrar con precisión sin un modelo de dominio adecuado para hacer referencia
Si usó una implementación ingenua y usó una entidad de usuario única, terminaría siendo un modelo de datos anémico lleno de captadores y establecedores, porque no podría representar completamente al usuario en todo el lugar.
Existen límites claros en el negocio, por lo que es útil modelarlos de esa manera. Un usuario que inicia sesión frente a un usuario en un sistema de nómina frente a un usuario que juega un juego son muy diferentes, incluso si son parte del mismo gran sistema.
Pensando de otra manera: ahora puede crear su código de gestión de desarrollador para que sea muy ligero e independiente del resto de su sistema. Puede usar tipos más precisos con menos equipaje de los que preocuparse. Es el paso para construir subsistemas más pequeños que eventualmente pueden extraerse en su propia aplicación.
fuente
Employeeno es unUser, tiene unUser. ElUseres simplemente una entidad a través de la cual una persona puede iniciar sesión y acceder a una o más aplicaciones dentro de la organización. Y unEmployeeno siempre tiene unUser. Además, normalmente no obtiene una aplicación simple para diferentes departamentos; típicamente, cada departamento tiene sus propias aplicaciones, cada una con sus propios modelos de dominio. Entonces, para mí, esta respuesta no ayuda a aclarar la necesidad de tener contextos acotados separados en la misma base de código.Te puedo dar otro ejemplo. Considere que tiene algún sistema de comercio electrónico. Tendría productos allí, sin embargo, los productos serán parte de al menos dos dominios diferentes:
Si tiene un contexto limitado para ambos dominios, su solución puede convertirse rápidamente en una gran bola de lodo porque comenzará a hacer referencias cruzadas. Al final ya no tendrás dos dominios. El inventario de su producto se estropeará con referencias del catálogo de productos y viceversa. Como resultado de esto, no podrá cambiar un dominio sin tocar otro, incluso si se da cuenta de que no es necesario. Sus modelos se vuelven dependientes entre sí y están estrechamente acoplados, y dependen de una mala manera, dependiendo de la implementación.
Sin embargo, si tiene dos contextos limitados, todos los cambios que realice en un dominio no afectarán al otro tan pronto como mantenga claros sus canales de comunicación. Significará que necesita tener duplicación de datos, pero este es el costo más bajo para pagar por una aplicación basada en componentes acoplados de forma incorrecta. Sus dominios pueden comunicarse entre sí mediante eventos de dominio. Incluso si no planea tener una aplicación basada en SOA al principio, podrá escalar a ese nivel cuando lo necesite con un esfuerzo relativamente bajo, ya que solo cambia el transporte para los eventos de su dominio, dejando la idea intacta.
Actualización: Hay una buena transmisión de habilidades en SkillsMatter, de Eric Evans. Da una analogía de la vieja historia, cuando varios ciegos describen a un elefante desde su perspectiva. Como cada hombre solo puede tocar una parte del elefante, lo describen como un "árbol", "pared", "serpiente", "cuerda". Y cada uno de esos hombres tiene razón dentro de su contexto. El contexto limitado es donde vive el lenguaje ubicuo. Fuera del contexto, estos términos pueden tener un significado completamente diferente, pero dentro del contexto, el lenguaje es el mismo en múltiples dominios. Greg Young sugiere comenzar a leer el libro azul del capítulo 11, ya que los conceptos fundamentales más importantes se explican allí. El enfoque en los patrones tácticos al comienzo del libro hace que este enfoque de "DDD-light" sea muy común,
fuente
Productclases comparten hipotéticamente la misma ID (por ejemplo, las dos tablas BC separadas tienen una clave externa para una tabla con una sola ID de producto)? ¿Quizás al comunicarse con Eventos de dominio podrían usar esa ID?