¿DDD limita los contextos y dominios?

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).

Considere una empresa que tiene algunos departamentos diferentes:

• Desarrollo de software
• HORA
• Contabilidad

¿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:

• Desarrollador
• Empleado
• Tenedor

El esfuerzo para crear una instancia de un usuario en cada contexto es considerablemente diferente. Quizás sea algo como esto:

• nuevo empleado (ssn, nombre, fecha de unión, fecha de nacimiento, género)
• Nuevo desarrollador (empleado, estación de trabajo, credenciales)
• nuevo beneficiario (empleado, rol)

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.

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:

• Catálogo de productos, donde guarda la descripción del producto y todos los atributos
• Inventario, donde tiene nivel de stock de producto

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,