Boundaries
Boundary de qué
Una boundary hace explícito dónde cambia una responsabilidad, autoridad, confianza, ownership, ciclo de vida o regla de contención. La palabra sola queda incompleta: boundary de qué, entre quiénes y respecto de qué regla. Una línea útil permite entender lo permitido a cada lado y qué interacción debe cruzarla.
En Commerce, Payments tiene autoridad sobre el ciclo de vida del pago. Orders puede solicitar autorización y observar resultados, pero no debería modificar directamente el estado privado de Payments. Esa regla describe una boundary de responsabilidad y autoridad. Todavía no exige procesos, repositorios o servidores separados.
Para el Atlas, boundary es un concepto arquitectónico abstracto cuyo alcance debe declararse. Distintos métodos pueden usarlo para límites de módulos, sistemas, confianza o ejecución. No tratamos todos esos sentidos como una taxonomía única ni como garantías intercambiables.
Diferentes reglas, límites que se superponen
Una boundary de responsabilidad delimita qué decide una parte. Una de módulos puede restringir acceso a implementación. Data ownership delimita autoridad sobre información. Una de deployment identifica qué se entrega conjuntamente; una de proceso delimita cierto entorno de ejecución.
Una trust boundary indica dónde cambian supuestos de confianza o autoridad técnica. Un límite de tenant distingue contextos de acceso y datos. Una transaction boundary define el alcance de una confirmación atómica. Una failure boundary señala dónde esperamos contener determinados efectos, con mecanismos que deben comprobarse.
Estas separaciones pueden coincidir o cruzarse. Payments e Inventory podrían conservar distintas autoridades y participar en una transacción local. Un mismo tenant puede usar varios servicios. Un deployment puede alojar varios módulos, y un servicio puede ejecutar para múltiples tenants.
La descripción necesita señalar qué representa cada línea. Usar una sola caja para todas las reglas puede ocultar que los límites reales difieren. Tampoco hace falta dibujar cada límite en toda conversación: elegir los relevantes permite analizar una preocupación sin confundirla con la arquitectura completa.
Boundary y Decomposition
decomposition establece unidades significativas y criterios de división. Boundaries aclara dónde terminan ciertas responsabilidades y qué accesos o efectos deberían restringirse. Nombrar dos components no demuestra que el límite entre ellos sea efectivo.
Orders y Payments pueden aparecer separados en un diagrama y compartir clases privadas, tablas y procedimientos internos. Si Orders cambia directamente una autorización, el reparto de autoridad declarado no se conserva. La revisión debe observar accesos reales, no solamente nombres.
El criterio de Parnas ayuda a revisar qué decisiones internas deberían permanecer ocultas a otras unidades. Lo usamos aquí para preguntar si un consumidor necesita conocer aquello que la división pretendía proteger, sin deducir que el ocultamiento requiera separación física. On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
También existe colaboración legítima entre unidades. Una boundary no prohíbe todo intercambio: delimita formas permitidas y autoridad. Solicitar cancelar una autorización mediante una operación pública difiere de sobrescribir su registro interno aunque ambas acciones afecten al mismo pago.
Boundary e Isolation
isolation pregunta qué efectos, recursos o consecuencias quedan contenidos y hasta dónde. Una boundary declara separación respecto de una regla; no demuestra que todas las interferencias se detengan allí.
Dos módulos pueden impedir acceso a sus clases internas y compartir memoria, CPU y conexiones. Eso protege ciertos cambios de implementación, pero no garantiza que uno sobreviva a un fallo global del proceso. Un pool separado puede contener conexiones y dejar compartido el servidor de almacenamiento.
También una frontera física tiene alcance limitado. Dos procesos pueden depender del mismo broker, credenciales o volumen. Separarlos contiene algunos efectos y conserva otros. Declarar «aislado» sin escenario y mecanismo convierte una boundary particular en una garantía excesiva.
La comprobación debe vincular regla, mecanismo y evidencia. Para contener consumo de conexiones hay que observar trabajo competidor y límites. Para impedir escrituras ajenas hay que comprobar permisos y rutas de acceso. Cada resultado habla de la propiedad ensayada, no de aislamiento universal.
Authority sobre datos y unidad de entrega
data-ownership establece quién interpreta y modifica información autoritativa. Esa autoridad suele formar una boundary semántica, pero no agota todos los límites arquitectónicos. Una boundary de confianza puede interesar aunque ningún participante sea owner de una base.
Payments puede controlar sus tablas y publicar capacidades usando el mismo servidor de datos que Inventory. La ubicación física compartida no obliga a compartir autoridad. Para sostener la regla se necesitan accesos compatibles: permisos, interfaces y disciplina revisada, según el entorno.
deployment describe unidades de instalación, actualización y reversión. Varios límites lógicos pueden existir dentro de una entrega común. Entregar Orders y Payments juntos no implica que Orders pueda escribir sus internals; desplegarlos por separado tampoco demuestra que deje de hacerlo.
Por eso conviene representar las correspondencias entre vistas. Views and Beyond distingue unidades de código, elementos de runtime y asignación al entorno, evitando que una separación visible en una estructura se interprete automáticamente como otra. SEI: Comparing Views and Beyond with ANSI-IEEE 1471-2000, sección 2.2.
Cómo se sostiene una boundary
| Mecanismo | Qué conviene verificar |
|---|---|
| Documentación y convenciones | Quién conoce la regla y cómo se detecta un incumplimiento. |
| Lenguaje o módulos | Qué implementación queda realmente inaccesible para consumidores. |
| Proceso y red | Qué accesos y efectos se restringen, y cuáles siguen posibles. |
| Storage y permisos | Quién puede leer o modificar estado privado. |
| Revisión y pruebas | Qué evidencia permite observar bypass y consecuencias del cambio. |
Una boundary documentada puede ser útil para coordinación, aunque no impida técnicamente un acceso. La protección del lenguaje puede detener ciertos imports. Permisos de almacenamiento pueden limitar escrituras. Cada mecanismo tiene un alcance que necesita describirse sin confundir intención con enforcement.
Separar físicamente puede fortalecer controles específicos y agregar serialización, operación, latencia y recuperación. No es automáticamente una mejora para toda regla. Si el problema es acceso accidental a implementación, una protección local puede ser suficiente; si exige contención de ejecución, puede hacer falta otro mecanismo.
Los controles también necesitan mantenimiento. Una nueva ruta administrativa, un job de reparación o una integración directa puede saltarse una boundary que el flujo habitual respetaba. Revisar excepciones evita que el límite sea fuerte únicamente en el ejemplo del diseño.
Boundaries débiles o permeables
Una boundary se debilita cuando el consumidor necesita conocer schema privado, modelo interno, secuencia de implementación o estados técnicos ajenos para completar su propia responsabilidad. Pasar por un método público no protege el límite si el contrato reproduce esas decisiones.
Orders que debe activar tres flags privados antes de invocar Payments participa en su workflow interno. Si cambia el proveedor y esa secuencia cambia, Orders también necesita modificarse. El límite declarado no localizó la variación que pretendía ocultar.
No todo conocimiento compartido es una fuga. El significado público de autorizado, las restricciones comerciales y una política acordada pueden ser dependencias legítimas. El análisis debe distinguir compromisos deliberados de detalles expuestos accidentalmente. dependency-structure permite seguir esas obligaciones y su propagación.
Una boundary excesivamente opaca también puede impedir comprender errores o cumplir requisitos. Ocultar información no significa volver inobservable el sistema. Hace falta exponer resultados y evidencia útiles sin convertir al consumidor en operador de toda la implementación privada.
Commerce sin separación física obligatoria
En un modular-monolith, Orders, Payments, Inventory y Shipping pueden compartir proceso y deployment. Payments conserva autoridad sobre pagos mediante operaciones públicas, implementación encapsulada y acceso a datos controlado. Compartir servidor de base de datos no invalida automáticamente esa boundary.
La colaboración puede usar llamadas locales y permitir una transacción entre responsabilidades cuando el diseño la admite. Su alcance debe ser explícito; disponer de atomicidad no concede permiso para escribir internals ajenos. El comportamiento sigue pasando por reglas acordadas.
Esa alternativa conserva fallos compartidos de runtime y costos de entrega conjunta. La boundary protege ciertas responsabilidades y cambios, sin prometer independencia de deployment o tolerancia a cualquier crash. Separar esas propiedades permite comparar alternativas sin convertir un monolito modular en microservices simulados.
Separación física con límites defectuosos
En otra variante, Orders y Payments tienen procesos, repositorios y pipelines separados. Si Orders escribe las tablas de Payments, los contratos filtran detalles y cada cambio requiere un release coordinado, la separación física convive con una boundary semántica débil.
microservices necesita analizar independencia efectiva y responsabilidades, además de unidades remotas. Contar servicios no demuestra que se haya protegido autoridad o localizado cambio. Puede haber razones para la coordinación, pero deben reconocerse en vez de prometer autonomía inexistente.
interfaces permite describir la superficie deliberada para cruzar el límite. connectors describe cómo colaboran los participantes. Ambos deben preservar la regla relevante; reemplazar HTTP por mensajes no corrige por sí solo un contrato que exige manipular estado privado.
Revisar límites y profiles
architecture-profile reúne combinaciones de límites lógicos, runtime, deployment, datos y operación. Un perfil no se identifica por cantidad de boundaries. Interesa qué decisiones agrupa y cuáles quedan abiertas según los drivers.
Para cada límite relevante, preguntar qué protege, quién tiene autoridad, cómo se cruza, qué bypass existe y qué sigue compartido. Después observar un cambio o fallo concreto de Commerce. Una boundary útil convierte separación abstracta en una regla comprensible y contrastable, sin prometer propiedades que corresponden a otros análisis.