Introducción
El mundo de la arquitectura de software es muy amplio y, a menudo, abstracto y confuso. Por esta razón, he creado esta guía para implementar Clean Architecture en C#.
Antes de sumergirnos en el código, es fundamental contextualizar las diferentes arquitecturas y patrones de diseño que utilizaremos. Abordaremos estos conceptos desde una perspectiva práctica y de alto nivel, apoyándonos en ejemplos cotidianos que luego veremos reflejados en nuestra implementación técnica.
¿Qué es la arquitectura de software?
La arquitectura de software es la estructura general de un sistema. A diferencia del diseño de software —que se centra en detalles de implementación o elementos tácticos—, la arquitectura involucra aquellas decisiones estratégicas a largo plazo que son difíciles de cambiar y que cimentan las bases de la aplicación.
Se define a través de la combinación de cuatro dimensiones fundamentales:
- Características de la arquitectura: Los criterios de éxito operacionales y las capacidades no funcionales que debe soportar el sistema (rendimiento, escalabilidad, seguridad).
- Componentes lógicos: Los bloques de construcción que conforman y estructuran el comportamiento del sistema.
- Estilo de arquitectura: El modelo o topología elegido como punto de partida para solucionar los requisitos (ej. microservicios, arquitectura por capas, orientada a eventos).
- Decisiones de arquitectura: Las reglas y restricciones estrictas sobre cómo deben construirse las partes del sistema (ej. definir qué capas tienen permitido comunicarse directamente con la base de datos).
Monorepo
Concepto: Es una estrategia de gestión de código fuente donde múltiples proyectos, aplicaciones y librerías comparten un único repositorio de Git. A diferencia de los poli-repositorios, permite realizar cambios atómicos que afectan a varios componentes simultáneamente, facilita el uso de herramientas de configuración compartidas y garantiza que todo el ecosistema evolucione de forma coherente bajo un mismo historial.
💡 Símil: Un gran centro comercial donde diferentes tiendas operan de forma independiente, pero comparten la misma infraestructura base (seguridad, estacionamiento, pasillos).
- Ventajas: Facilidad para refactorizar código compartido, gestión de dependencias unificada y visibilidad total del ecosistema.
- Desventajas: Tiempos de CI/CD más largos y necesidad de herramientas de compilación optimizadas.
Bounded Context (Contexto Delimitado)
Concepto: Es un pilar del diseño guiado por el dominio (DDD) que define una frontera lógica dentro de la cual un modelo de dominio y un "Lenguaje Ubicuo" son aplicables y consistentes. Dentro de este límite, cada término tiene un significado único y preciso. Esto permite que diferentes partes del sistema manejen conceptos que suenan igual (ej. "Producto") pero que tienen atributos y comportamientos distintos según su contexto (ej. Catálogo vs. Inventario).
💡 Símil: La palabra "Célula". En biología es la unidad estructural básica de los seres vivos; en política, es un pequeño grupo de acción. El contexto define el significado exacto.
- Ventajas: Elimina la ambigüedad conceptual y otorga autonomía a los equipos de desarrollo.
- Desventajas: Requiere un análisis exhaustivo y profundo del negocio antes de programar.
Monolito Modular
Concepto: Un estilo arquitectónico que despliega toda la aplicación como una única unidad (un solo proceso), pero cuya estructura interna está rígidamente dividida en módulos independientes y altamente cohesivos. Cada módulo encapsula su propia lógica y datos, comunicándose con otros a través de interfaces bien definidas (contratos). Esto evita la complejidad de red de los microservicios sin sacrificar la separación de responsabilidades.
💡 Símil: Un hotel. Es un solo gran edificio, pero los huéspedes de una habitación no pueden entrar a otra sin pasar por los protocolos de acceso definidos.
- Ventajas: Simplicidad operativa, baja latencia en la comunicación interna y una ruta de migración sencilla hacia microservicios en el futuro.
- Desventajas: Si la disciplina se relaja y no se respetan los límites, el sistema puede degradarse rápidamente en una "Gran Bola de Barro" (Big Ball of Mud).
Arquitectura Hexagonal (Ports & Adapters)
Concepto: Patrón de diseño que desacopla el núcleo de la aplicación (la lógica de negocio) de las tecnologías externas (bases de datos, frameworks de UI, servicios de terceros). El núcleo define interfaces llamadas Puertos (Ports), mientras que los detalles técnicos implementan estas interfaces a través de Adaptadores (Adapters). Así, el dominio es agnóstico a la tecnología.
💡 Símil: A tu computadora no le importa si conectas un mouse de marca X o un teclado de marca Y, siempre y cuando utilicen el conector estándar USB (el puerto).
- Ventajas: Testeabilidad extrema (facilita los mocks) y capacidad para cambiar infraestructura sin tocar una sola línea de código de negocio.
- Desventajas: Introduce un mayor nivel de indirección, requiriendo más archivos e interfaces.
Arquitectura Screaming (Arquitectura que "Grita")
Concepto: Propuesto por Robert C. Martin ("Uncle Bob"), este principio sostiene que la estructura de carpetas de un proyecto debe comunicar de inmediato el propósito del software. Al observar el directorio raíz, cualquier desarrollador debería identificar si es un sistema escolar, un e-commerce o una red social, en lugar de ver simples carpetas técnicas dictadas por el framework (ej. Controllers, Services, Views).
💡 Símil: Un plano arquitectónico. Al verlo, sabes si es una casa o un hospital por la distribución de las habitaciones, no por la marca de tinta con la que se dibujó el plano.
- Ventajas: Navegación intuitiva orientada a características; el negocio es el protagonista del código.
- Desventajas: Requiere abandonar convenciones MVC tradicionales que muchos frameworks imponen por defecto.
CQRS (Command Query Responsibility Segregation)
Concepto: Patrón que separa estructuralmente las operaciones que modifican el estado de los datos (Comandos) de aquellas que únicamente devuelven datos (Consultas). Esto permite escalar y optimizar ambos caminos de forma independiente. Los comandos garantizan la integridad de las reglas de negocio, mientras que las consultas se centran en la velocidad, pudiendo incluso leer de bases de datos materializadas o desnormalizadas.
💡 Símil: En una biblioteca municipal, el mostrador para buscar y leer un catálogo de libros (consulta) está separado del mostrador de administración donde se registran las devoluciones o nuevos ingresos (comando).
- Ventajas: Optimización de rendimiento a medida, escalabilidad independiente y modelos de lectura simplificados.
- Desventajas: Complejidad inicial más alta y necesidad de lidiar con la consistencia eventual.
DDD (Domain-Driven Design)
Concepto: Una metodología de desarrollo centrada en resolver problemas complejos mediante una colaboración profunda entre expertos del dominio (negocio) y desarrolladores técnicos.
💡 Símil: Un sastre que diseña y construye un traje a la medida exacta de las necesidades de su cliente, en lugar de vender una prenda estándar de talla única.
- Ventajas: El código refleja de manera fiel y exacta la realidad y los procesos de la empresa.
- Desventajas: Curva de aprendizaje empinada y puede ser excesivo para sistemas simples (CRUD).
DDD Estratégico
Determina dónde dividir el sistema y cómo alinear los equipos. Sus componentes clave son:
- Lenguaje Ubicuo: Vocabulario común y riguroso compartido entre negocio y técnica, presente en las reuniones y explícito en el código.
- Dominios y Subdominios: Identificación del corazón del negocio (Core Domain) frente a sistemas de apoyo o genéricos.
- Contextos Delimitados (Bounded Contexts): Fronteras explícitas donde un modelo de dominio es válido.
- Mapeo de Contextos (Context Mapping): Definición de las reglas de integración y comunicación entre distintos Bounded Contexts.
DDD Táctico
Determina cómo escribir el código y estructurar las clases para resolver la lógica. Sus elementos principales son:
- Entidades (Entities): Objetos definidos por una identidad única y constante en el tiempo, independientemente de si sus atributos cambian (ej. un Usuario).
- Objetos de Valor (Value Objects): Objetos inmutables que describen características, pero no tienen identidad propia (ej. Dirección o Dinero).
- Agregados (Aggregates): Clúster de Entidades y Objetos de Valor tratados como una unidad transaccional. Tienen una "Raíz" (Aggregate Root) que controla el acceso y garantiza la consistencia.
- Repositorios (Repositories): Contratos que gestionan la persistencia de los Agregados, ocultando la base de datos al dominio.
- Servicios de Dominio (Domain Services): Lógica de negocio que involucra a múltiples entidades y no encaja de forma natural en ninguna de ellas.
- Eventos de Dominio (Domain Events): Notificaciones sobre hechos relevantes que ya han ocurrido en el dominio, útiles para detonar acciones secundarias.
Patrón Outbox
Concepto: Patrón que resuelve el problema de la "Doble Escritura" (guardar en base de datos y publicar un evento en un bus de mensajes al mismo tiempo). Funciona guardando el evento en una tabla específica (Outbox) dentro de la misma transacción que el cambio principal del negocio. Un proceso asíncrono posterior (un relay o middleware) lee esta tabla y empuja el mensaje al bus, garantizando que el evento se publique al menos una vez (At-Least-Once delivery).
💡 Símil: El buzón de salida de una oficina. Terminas tu carta y la dejas ahí (transacción completada). Sabes que, eventualmente, el cartero pasará a recogerla y despacharla.
- Ventajas: Garantiza la consistencia eventual entre el estado de la base de datos y la mensajería externa sin requerir transacciones distribuidas.
- Desventajas: Requiere infraestructura o procesos adicionales (workers) para leer y limpiar la tabla Outbox.
Patrón Inbox
Concepto: El complemento del patrón Outbox, aplicado en el servicio receptor. Registra cada identificador de mensaje entrante en una tabla Inbox antes de procesarlo (o en la misma transacción del procesamiento). Si llega un mensaje duplicado (por reintentos de la red), el receptor consulta su Inbox, detecta que ya lo procesó y lo descarta, logrando así un comportamiento idempotente.
💡 Símil: Una secretaria que anota en un registro cada llamada atendida. Si el mismo cliente vuelve a llamar por el mismo asunto debido a que se cortó la línea, ella revisa su registro y evita duplicar la tarea.
- Ventajas: Tolerancia a fallos, evita la corrupción de datos por procesamiento de mensajes duplicados.
- Desventajas: Aumenta el uso de almacenamiento y requiere limpieza periódica de registros antiguos.
Sagas
Concepto: Un patrón para gestionar flujos de trabajo o procesos de negocio de larga duración que abarcan múltiples microservicios o contextos. Dado que los bloqueos de base de datos y las transacciones distribuidas (ACID) son un antipatrón en la nube, la Saga coordina una secuencia de pasos locales asíncronos. Si un paso falla en la cadena, la Saga dispara de forma automática Transacciones de Compensación (acciones que deshacen lógicamente los pasos previos que ya habían tenido éxito).
💡 Símil: Reservar un viaje online. Si el sistema logra comprar tu vuelo pero luego falla al reservar el hotel, no puede "hacer rollback" a la tarjeta de crédito mágicamente; en su lugar, inicia un proceso de cancelación del vuelo y solicitud de reembolso (compensación).
- Ventajas: Mantiene la consistencia de los datos en arquitecturas distribuidas de forma escalable.
- Desventajas: Su diseño es complejo, requiere manejar múltiples escenarios de error y es difícil de depurar visualmente.
Top comments (0)