¿DDD limita los contextos y dominios?

16

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

lko
fuente
Me parece que lo único que define contextos limitados separados es la necesidad de diferenciar la lingüística y las diferencias operativas asociadas, es decir, se llama producto en un área y producto en otra área, pero son diferentes, por lo que necesitamos dos productos y ambos pueden ' t estar en el mismo modelo (mismo nombre, etc.). Entonces, ¿por qué no cambiamos los nombres para representar su semántica sutilmente diferente? Podrían tener un modelo para gobernarlos a todos. Los subdominios son naturales pero no estoy viendo contextos limitados en este momento. Solo pienso en voz alta aquí ...
Ashley Aitken
Supongo que ya se dio cuenta de por qué es rentable dividir su dominio en contextos. Entonces, lo que podría ser útil ahora es la forma correcta de identificarlos, definir los límites del contexto. Así es como lo hago: medium.com/@wrong.about/…
Zapadlo

Respuestas:

20

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.

Adrian Schneider
fuente
Gracias por el ejemplo de apoyo que ayuda a ilustrar las diferentes necesidades de los 3 BC.
lko
No es la forma en que estoy acostumbrado a ver estos conceptos: normalmente, un Employeeno es un User, tiene un User. El Useres 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 un Employeeno siempre tiene un User. 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.
Rogério
@ Rogério su objeción es en realidad un hermoso ejemplo de por qué es importante definir adecuadamente los lenguajes ubicuos utilizados dentro de cada contexto limitado :)
MauganRa
Simplemente me pregunto en los casos en que tenemos un sistema de gestión de clientes, cuando llamamos por teléfono para consultar nuestros pedidos, facturación, etc., nos ponen en espera mientras nos transfieren al departamento correspondiente. El conocimiento del dominio de cada departamento entra en juego, para molestia del cliente en estos escenarios. Tal vez podamos culpar a DDD por forzar la separación entre estos contextos.
Andez
16

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,

Alexey Zimarev
fuente
1
+1 por mostrar también la duplicación. es un poco confuso al principio ("¡¿Estoy haciendo esto mal ?!) pero es completamente natural, cualquiera en muchos casos, requerido.
Adrian Schneider
En este escenario, ¿estas 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?
lko
1
Todo depende de qué almacenamiento se elija. No es necesario usar la identificación técnica para referir dominios cruzados. Tampoco es aconsejable hacer una comunicación entre contextos.
Alexey Zimarev
1
Parece que es hora de sacar el libro azul del estante y leer esos capítulos posteriores
Markus Pscheidt