Internal Structure

Pregunta de entrada

¿Cómo organizamos responsabilidades y dependencias dentro de una unidad arquitectónica? La unidad puede ser un monolith, un módulo, un microservice, una aplicación de escritorio o un backend. Este MOC conserva navegación y síntesis; los canónicos desarrollan definiciones, fuerzas y consecuencias.

architecture-profiles trata principalmente decisiones del sistema y sus grandes boundaries. decomposition establece qué unidades y fronteras observamos; Internal Structure mira el interior de una de ellas. Las dimensiones pueden componerse jerárquicamente; architectural-drivers permite recuperar por qué necesitamos cada decisión.

Recorridos por pregunta

Pregunta	Documento
¿Cómo agrupar responsabilidades con reglas entre capas?	layered-architecture
¿Cómo proteger la aplicación de interacciones tecnológicas?	ports-and-adapters
¿Qué quiso comunicar el hexágono de Cockburn?	hexagonal-architecture, perspectiva del canonical Ports and Adapters.
¿Cómo situar el dominio en el centro?	onion-architecture
¿Cómo separar políticas y mecanismos externos?	clean-architecture
¿Cómo acercar código que cambia por caso de uso?	vertical-slice-architecture
¿Quiero un core estable extensible mediante plugins?	microkernel
¿Quiero definir extensibility points para módulos opcionales?	plugin-architecture
¿Quiero procesar información mediante stages componibles?	pipe-and-filter
¿Según qué criterio debería organizar el código?	code-partitioning-strategies

Para una primera lectura, seguir Layered → Ports and Adapters y su perspectiva histórica → Onion/Clean → Vertical Slice. Para extensibilidad o transformación, entrar directamente por las preguntas correspondientes.

Ideas organizadoras

Approach	Primary organizing idea
Layered	Responsabilidades técnicas y capas lógicas.
Ports and Adapters / Hexagonal	Frontera inside/outside y contratos de interacción.
Onion	Capas de dependencias alrededor del dominio.
Clean	Niveles de políticas y Dependency Rule.
Vertical Slice	Caso de uso o feature como eje de cambio.
Microkernel	Núcleo estable ampliado por extensiones.
Plugin Architecture	Host y extension points.
Pipe and Filter	Transformaciones y etapas componibles de procesamiento.
Code Partitioning	Práctica para elegir cómo organizar código.

La tabla no es una clasificación exclusiva ni una escala de madurez. Code Partitioning no define una única arquitectura; Hexagonal conserva el nombre histórico de Ports and Adapters, sin crear otro canonical.

Ports and Adapters, Onion y Clean

Aspecto	Ports and Adapters	Onion	Clean
Énfasis	Interacciones inside/outside.	Dominio central.	Políticas y Dependency Rule.
Modelo	Ports y adapters.	Capas concéntricas de comportamiento.	Entities, Use Cases y boundaries.
Dependencias de código	Adaptadores conocen contratos interiores.	Hacia zonas más centrales.	Hacia políticas de mayor nivel.
Origen	Alistair Cockburn.	Jeffrey Palermo.	Robert C. Martin, sintetizando ideas previas.

Comparten protección de lógica interna, fronteras explícitas, inversión de dependencias y pruebas aisladas. Difieren principalmente en énfasis, terminología, modelo y detalle de layering. Tecnología reemplazable no significa sustitución gratuita: deben conservarse sus obligaciones.

Algunas fuentes agrupan nombres ampliamente; los canónicos conservan las formulaciones originales. No se compara Hexagonal contra Ports and Adapters como arquitecturas competidoras.

Layered, inversión y Vertical Slice

Examinar imports y tipos, no solamente diagramas. En una variante Layered tradicional, Business puede depender de Data Access concreto; con inversión, Infrastructure conoce contratos de Application/Domain. Layered no siempre depende hacia database, y el flujo runtime no equivale a la dirección de dependencias de código.

Layer no es tier: separar responsabilidades no decide cuántos procesos o fronteras físicas existirán.

Layered destaca responsabilidad técnica; Vertical Slice destaca caso de uso. Pueden componerse con un núcleo protegido. Vertical Slice no elimina infraestructura o domain model, ni equivale a CQRS o MediatR. Para sus costos y reglas concretas, continuar con los canónicos.

Microkernel frente a Plugin Architecture

Microkernel centra el diseño en un core estable y sus extensiones. Plugin Architecture enfatiza host, contratos y mecanismos de contribución. Hay fuerte superposición y variación terminológica; muchas implementaciones Microkernel usan plugins, pero un subsistema de plugins no obliga a describir todo el sistema como Microkernel.

Núcleo pequeño no significa trivial; plugin no implica aislamiento automático. Revisar contratos/versioning, lifecycle y permisos en los canónicos. Un modular-monolith puede ser extensible, pero no todos sus módulos son plugins.

Pipe and Filter frente a Layered

Layered organiza responsabilidades o abstracciones; Pipe and Filter organiza transformaciones y su composición. Una pipeline puede existir dentro de una aplicación por capas. Una etapa no equivale necesariamente a una capa.

Una cadena de métodos no prueba independencia; un pipe no equivale a una queue. Para presión entre etapas y recuperación, seguir los enlaces del canonical hacia backpressure, flow-control, queue-management, retry e idempotency.

Code Partitioning frente a arquitectura

Particionar código selecciona criterios de agrupamiento; la arquitectura establece compromisos y límites con consecuencias adicionales. Carpetas técnicas no prueban Layered y carpetas por feature no prueban Vertical Slice. Code partition tampoco equivale a deployment partition.

La práctica permite combinar módulo → caso de uso → responsabilidades internas. Revisar contratos, ownership y restricciones efectivos antes de deducir una arquitectura de la forma del repositorio.

Composiciones plausibles

Modular Monolith
└── Plugin-based extension system
 
Microservice
└── Pipe and Filter processing pipeline
 
Monolith
└── Layered Architecture
    └── Plugin subsystem
 
Modular Monolith
└── Domain modules
    └── Vertical Slices

monolith, modular-monolith y microservices describen perfiles; los ejemplos ilustran decisiones interiores posibles. No son recomendaciones universales ni garantías de compatibilidad, aislamiento o deployment independiente.

architecture-profile conserva los ejes del sistema completo. architectural-pattern y architecture-pattern-terminology permiten examinar alcances y usos de fuentes sin clasificar solamente por etiquetas.

Cobertura y continuación

La rama Internal Structure del Knowledge Map V0.3 tiene ahora sus entradas iniciales materializadas. Eso no vuelve definitivas sus variantes ni crea nuevos contratos. presentation-patterns continúa hacia Frontend and Client Architecture: MVC, MVP y MVVM organizan interacción UI y pueden componerse con las reglas interiores aquí comparadas, sin reemplazarlas.