Layered Architecture

Qué organiza

Layered Architecture agrupa responsabilidades en capas lógicas y establece reglas deliberadas sobre qué puede depender de qué. La abstracción ofrecida por una capa permite que sus consumidores trabajen sin conocer todos sus detalles. El valor está en esas responsabilidades y contratos, no en distribuir archivos entre carpetas llamadas Controllers, Services y Repositories.

Una aplicación de escritorio, un backend o un monolith pueden usar capas. Esa elección organiza el interior de una unidad; no decide por sí misma cómo se despliega el sistema. internal-structure conecta esta dimensión con otras formas de organizar código.

Layer no es tier

Una layer es una separación lógica. Un tier suele representar una separación física, de deployment o runtime. Tres capas pueden ejecutarse dentro de un proceso; dividir una aplicación entre tres procesos tampoco garantiza tres responsabilidades bien encapsuladas. Microsoft distingue explícitamente ambos términos y las variantes abiertas y cerradas en su descripción de N-tier.

Por ejemplo, Presentation, Application y Data Access pueden compilarse en bibliotecas distintas entregadas juntas. Separar Data Access en un servidor introduce red, fallos parciales y compatibilidad de protocolos: ya no es solamente reorganizar dependencias locales. El número de cajas del dibujo no permite deducir esos costos.

Responsabilidades y dirección

Una variante tradicional puede representarse así:

Dependencias de código permitidas en este ejemplo:
 
Presentation → Application → Business → Data Access

Presentation interpreta una interacción; Application coordina el caso de uso; Business conserva reglas; Data Access traduce operaciones de almacenamiento. Es una distribución posible, no una lista universal ni una exigencia de cuatro capas.

El esquema debe aclarar si sus flechas representan imports, llamadas o flujo de datos. Si Business importa clases concretas de persistencia, cambios de esa tecnología pueden alcanzar lógica de negocio. Separar carpetas no elimina esa dependencia.

También es posible invertirla: Application define un contrato que necesita y el adaptador de persistencia lo implementa. Data Access depende entonces de ese contrato interior, aunque el caso de uso invoque al adaptador en runtime. La guía de arquitecturas web de Microsoft contrapone precisamente el layering tradicional y la inversión de dependencias. Layered no implica siempre dependencias dirigidas hacia la base de datos.

Capas cerradas, abiertas y bypass

Una capa cerrada obliga a atravesar la capa intermedia prevista; una abierta permite omitirla bajo reglas explícitas. Mark Richards desarrolla esta distinción y el problema de atravesar capas sin trabajo significativo en Software Architecture Patterns.

En una aplicación de autorizaciones, una regla cerrada puede impedir que Presentation consulte directamente datos de aprobaciones: Application valida el permiso y Business evalúa la transición. Abrir esa ruta para una consulta de lectura exige conservar autorización y ownership de datos. «Es más rápido» no explica dónde quedan esas garantías.

Una política útil especifica consumidores, operaciones y excepciones. Permitir un bypass concreto no autoriza acceso arbitrario a todo lo situado debajo. Un módulo común tampoco debería convertirse en una vía para importar cualquier detalle: sus dependencias cuentan tanto como las del resto.

Change isolation, pruebas y coupling

Supongamos que cambia cómo se almacena una autorización. Si los consumidores trabajan con un contrato estable, el cambio puede quedar encapsulado. Si reciben entidades del ORM, construyen consultas específicas o conocen sus transacciones, la frontera deja escapar decisiones. La abstracción debe representar operaciones y garantías relevantes, no envolver una biblioteca copiando toda su API.

Las pruebas pueden distinguir reglas de negocio, coordinación y persistencia. Un fake permite explorar estados sin un servidor, mientras que pruebas de integración comprueban consultas, restricciones y comportamiento transaccional real. Probar solo mocks puede validar una conversación equivocada con éxito.

La separación también tiene costos: navegación entre archivos, conversiones, contratos y coordinación cuando un cambio atraviesa varias responsabilidades. Una capa genérica compartida por todo el sistema puede aumentar change coupling. En un modular-monolith, conviene preguntar si las capas se organizan dentro de cada módulo o si una capa horizontal permite atravesar sus límites.

Sinkhole y límites de aplicación

El sinkhole describe recorridos donde muchas capas se limitan a reenviar una petición. En nuestro ejemplo, crear tres servicios que solo delegan la misma llamada agrega puntos de mantenimiento sin aislar una decisión clara. Antes de conservarlos, preguntar qué contrato, política o evolución independiente justifican cada paso.

Una delegación breve sí puede ser valiosa si protege autorización, compatibilidad o un límite de ownership. Contar líneas de lógica no basta para identificar una capa inútil. Tampoco eliminar todos los pasos intermedios mejora automáticamente el diseño.

Esta organización resulta útil cuando responsabilidades estables y reglas comprensibles ayudan a contener cambios. Se vuelve frágil cuando las capas son nombres sin restricciones o cuando toda feature obliga a modificar abstracciones compartidas sin una razón común.

Composición y revisión

pipe-and-filter organiza transformaciones y puede existir dentro de una aplicación por capas. code-partitioning-strategies distingue agrupamiento físico y reglas arquitectónicas: tener carpetas Controllers/Services/Repositories no demuestra layering.

ports-and-adapters, onion-architecture y clean-architecture precisan otras formas de proteger el interior mediante contratos y dirección de dependencias. Pueden representarse por capas; la comparación debe mirar sus reglas reales.

vertical-slice-architecture prioriza casos de uso como eje de organización. Puede agrupar cada feature y mantener separaciones lógicas dentro de ella. Para revisar una propuesta Layered, pedir responsabilidades, imports permitidos, excepciones de bypass, datos que cruzan fronteras y pruebas que demuestren encapsulación. Un diagrama horizontal no sustituye esas respuestas.