Esta carta es una Territory card. No se materializa en carpeta, interfaz o clase a nivel de código, pero es importante como ideaa reflejar por si misma. Por eso existe la carta.

Especificaciones

Al ser una Territory card, su complejidad es de 0

Su función principal es representar todo lo que engloba el negocio. Lo que sea negocio va dentro de este territorio sin discusión.

Representa el “Problem space”, donde se ubican las necesidades y objetivos de los usuarios, las partes interesadas o “Stakeholders” y el “Application context” para el que está diseñado el sistema.

El dominio encapsula el conocimiento, actividades y la influencia de diversas partes interesadas. Esto incluye comprender las complejidades de las operaciones comerciales, el flujo de trabajo de diferentes usuarios, las reglas que rigen los procesos y los objetivos que se espera que el sistema logre.

Desarrollar una comprensión profunda del dominio requiere colaboración entre diferentes roles dentro del proyecto. Esto incluye a expertos del dominio, analistas de negocios, desarrolladores… El DDD promueve equipos interfuncionales que trabajan juntos para refinar el modelo de dominio, asegurando que todos compartan una comprensión común del espacio del problema. De ahí que sea tan importante el concepto de Lenguaje ubiquo que promueve la carta “Domain”.

Básicamente cada concepto debería tener sentido de cara a negocio y debería constar en un glosario para darle contexto. Si hay algo importante de verdad en un bounded context, este sería un glosario bien definido. El glosario es imprescindible. Alinea todos los que conforman el equipo y la parte de negocio. También es la manera más fácil de incorporar miembros nuevos al equipo.

Como relaciones, podemos poner todos los elementos y capas que contiene, como Domain layer, Domain services, Domain model, Aggregates y Value objects.