Un Bounded Context es un limite explicito dentro del cual un modelo de dominio tiene significado consistente. Fuera de ese limite, los mismos terminos pueden representar conceptos distintos con reglas distintas. El Bounded Context es el patron estrategico central de Domain-Driven Design: define donde un modelo aplica y donde no.
La motivacion no es organizacional ni tecnica en primera instancia. Es semantica. Cuando un equipo intenta mantener un unico modelo unificado para todo el negocio, los terminos empiezan a acumular significados ambiguos, las reglas de negocio se contaminan entre areas, y el modelo se convierte en un compromiso que no representa bien ninguna parte del dominio. El Bounded Context resuelve esto estableciendo fronteras donde cada modelo puede ser preciso y autonomo.
En sistemas no triviales, la ausencia de Bounded Contexts produce lo que Eric Evans denomina un Big Ball of Mud: un modelo monolitico donde los cambios en un area producen efectos cascada impredecibles en otras. El costo de cambio crece de forma no lineal con el tamano del modelo.
Establecer Bounded Contexts correctamente permite:
- Autonomia de equipos: cada contexto puede evolucionar independientemente con su propio ritmo de deployment.
- Precision del modelo: los conceptos se definen sin ambiguedad dentro de su contexto, lo que reduce bugs semanticos.
- Bajo acoplamiento estructural: los contextos se comunican a traves de contratos explicitos, no mediante dependencias internas compartidas.
La decision de donde trazar los limites es una de las decisiones de diseno mas impactantes en un sistema. No se deriva del codigo: se deriva de la comprension del dominio, del Ubiquitous Language, y de donde ese lenguaje cambia de significado.
Este repositorio ilustra el patron con un dominio de autorizaciones medicas donde el concepto de "autorizacion" existe en dos contextos con significados fundamentalmente distintos.
Modela la autorizacion desde la perspectiva clinica. Aqui una autorizacion (ClinicalAuthorization) se evalua contra un protocolo medico para determinar si un procedimiento esta clinicamente justificado dado un diagnostico.
clinicalcontext/
domain/
model/
ClinicalAuthorization.java -- Aggregate Root
AuthorizationId.java -- Value Object (identidad)
ClinicalStatus.java -- Value Object (PENDING, APPROVED, REJECTED)
DiagnosisCode.java -- Value Object
MedicalProcedure.java -- Value Object
service/
ClinicalProtocol.java -- Domain Service (interfaz)
El lenguaje de este contexto habla de diagnosticos, procedimientos, protocolos clinicos y estados clinicos. No sabe nada de planes, montos ni cobertura.
Modela la autorizacion desde la perspectiva de cobertura del seguro. Aqui una autorizacion (CoverageAuthorization) determina si el plan del miembro cubre el monto solicitado y calcula cuanto se autoriza financieramente.
coveragecontext/
domain/
model/
CoverageAuthorization.java -- Aggregate Root
CoverageAuthorizationId.java -- Value Object (identidad)
MemberId.java -- Value Object
Plan.java -- Value Object
El lenguaje de este contexto habla de miembros, planes, limites anuales y montos autorizados. No sabe nada de diagnosticos ni protocolos clinicos.
El termino "autorizacion" aparece en ambos contextos, pero no es el mismo concepto:
| Aspecto | Clinical Context | Coverage Context |
|---|---|---|
| Pregunta que responde | Es clinicamente apropiado? | Esta cubierto por el plan? |
| Datos centrales | Diagnostico, procedimiento | Miembro, plan, monto |
| Criterio de evaluacion | Protocolo clinico | Limite financiero del plan |
| Resultado | APPROVED / REJECTED | Monto autorizado (puede ser $0) |
Si se modelaran en una unica clase, esta clase tendria dos razones para cambiar, dos lenguajes mezclados, y reglas de negocio que no tienen relacion entre si acopladas artificialmente. El Bounded Context evita esto por diseno.
El AuthorizationOrchestrator en la capa de aplicacion coordina ambos contextos sin mezclar sus modelos. Primero evalua la autorizacion clinica; si pasa, evalua la cobertura. Cada contexto opera con sus propias reglas, su propio Aggregate Root, y su propio lenguaje.
clinicalAuthorization.evaluate(protocol); // Clinical Context
coverageAuthorization.evaluateCoverage(); // Coverage ContextEl orquestador no interpreta ni transforma los modelos internos de cada contexto. Solo invoca comportamiento y consulta resultados a traves de la interfaz publica de cada Aggregate Root. Esta es la forma correcta de integrar Bounded Contexts a nivel de aplicacion: coordinacion sin acoplamiento semantico.
El Bounded Context no opera de forma aislada en DDD. Trabaja en conjunto con:
- Context Map: documenta las relaciones entre Bounded Contexts (Customer-Supplier, Conformist, Anti-Corruption Layer, etc.).
- Ubiquitous Language: cada Bounded Context tiene su propio lenguaje ubicuo. El limite del contexto es el limite del lenguaje.
- Anti-Corruption Layer: cuando dos contextos necesitan comunicarse pero sus modelos son incompatibles, un ACL traduce entre ellos protegiendo la integridad de cada modelo.
- Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
- Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.