Introduccion

El mundo de la arquitectura de software es muy amplio y muchas veces muy abstracto y confuso, por eso decidi hacer una guia para implementar Clean Arquitecture en C#. Pero antes de ir a la implementacion, es necesario dar contexto sobre las diferentes arquitecturas y patrones de diseno que vamos a implementar. El contexto es un poco superficial, pero con ejemplos para entenderlo desde un punto de vista practico, que luego veremos reflejado en la implementacion que haremos.

Que es la arquitectura de software?

La arquitectura de software es la estructura general de un sistema y se define a través de la combinación de cuatro dimensiones fundamentales. A diferencia del diseño, que se centra en detalles de apariencia o elementos tácticos, la arquitectura involucra aquellas decisiones estratégicas a largo plazo que son difíciles de cambiar e impactan las bases de la aplicación.

Las cuatro dimensiones que componen la arquitectura de un sistema son:

1. Características de la arquitectura: Son los criterios de éxito operacionales y las capacidades que debe soportar el sistema.
2. Componentes lógicos: Son los bloques de construcción que conforman y estructuran el comportamiento del sistema.
3. Estilo de arquitectura: Es el modelo o topología que se elige como punto de partida para implementar una solución a los requisitos dados, como por ejemplo elegir microservicios o una arquitectura por capas.
4. Decisiones de arquitectura: Son las reglas y restricciones estrictas sobre cómo deben construirse las partes del sistema, como por ejemplo, definir qué capas específicas tienen permitido comunicarse directamente con una base de datos.

Monorepo

Concepto: 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 y versionada bajo un mismo historial.

• Símil: Un gran centro comercial, donde diferentes tiendas comparten infraestructura (seguridad, estacionamiento), pero operan de forma independiente.
• Ventajas: Facilidad para refactorizar código compartido, gestión de dependencias unificada y visibilidad total.
• Desventajas: Tiempos de CI/CD más largos; requiere herramientas de build optimizadas.

Bounded Context (Contexto Delimitado)

Concepto: Un pilar de 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 para el negocio. Esto permite que diferentes partes del sistema manejen conceptos que suenan igual (ej. "Producto") pero que tienen atributos y comportamientos totalmente distintos según su contexto (ej. Catálogo vs. Inventario).

• Símil: La palabra "Célula", en biología es la unidad morfológica, funcional y estructural más pequeña y básica de todos los seres vivos, en política es un grupo. El contexto define la definición.
• Ventajas: Elimina la ambigüedad y permite autonomía entre equipos.
• Desventajas: Requiere un análisis profundo del negocio inicial.

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á 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. Esto evita la complejidad de la red y el despliegue de los microservicios, sin sacrificar la separación de responsabilidades.

• Símil: Un hotel, es un solo edificio, pero los huéspedes de una habitación no pueden entrar a otra sin pasar por protocolos definidos.
• Ventajas: Simplicidad operativa (un solo proceso), baja latencia y fácil transición a microservicios.
• Desventajas: Si no se respetan los límites, puede degradarse en un "Big Ball of Mud" o "Gran Bola de Barro".

Arquitectura Hexagonal (Ports & Adapters)

Concepto: Patrón de diseño que busca desacoplar 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 "Ports" (Puertos) y los detalles técnicos implementan estas interfaces a través de "Adapters" (Adaptadores). El negocio es agnóstico a la tecnología y puede ser probado o cambiado sin modificar el código de dominio.

• Símil: A la PC no le importa si conectas un mouse o un teclado, siempre que usen el conector USB (puerto).
• Ventajas: Testeabilidad extrema y facilidad para cambiar de tecnología sin tocar el negocio.
• Desventajas: Introduce mayor número de 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 y el dominio del software. Al observar el directorio raíz, uno debería ser capaz de identificar si es un sistema de gestión escolar, un ecommerce o una red social, en lugar de ver simplemente carpetas genéricas del framework (ej. Controllers, Services, Views).

• Símil: Un plano arquitectónico: Sabes si es una casa o un hospital por la forma de las habitaciones, no por el tipo de tinta del plano.
• Ventajas: Navegación intuitiva; el negocio es el protagonista.
• Desventajas: Rompe con convenciones MVC tradicionales.

CQRS (Command Query Responsibility Segregation)

Concepto: Patrón arquitectónico que separa las operaciones que modifican el estado (Commands) de las que solo devuelven datos (Queries). Esto permite optimizar cada camino de forma independiente: los comandos se enfocan en la integridad y las reglas de negocio, mientras que las consultas se enfocan en el rendimiento y la flexibilidad de la interfaz de usuario, pudiendo usar incluso diferentes modelos de datos o bases de datos de lectura.

• Símil: En una biblioteca, el proceso para buscar un libro (lectura) es distinto al de registrar una devolución (escritura).
• Ventajas: Optimización de rendimiento independiente y escalabilidad.
• Desventajas: Mayor complejidad inicial en el modelo de datos.

DDD (Domain-Driven Design)

Concepto: Una metodología de desarrollo de software centrada en resolver problemas complejos de negocio mediante una colaboración estrecha entre expertos del dominio y desarrolladores.

DDD estrategico

Sus componentes clave incluyen:

• Lenguaje Ubicuo: Un lenguaje común y riguroso, compartido por expertos en el negocio y desarrolladores, utilizado en el código y en la comunicación diaria para evitar malentendidos.
• Dominios y Subdominios: Identificación de las áreas centrales del negocio (Core Domain) y las áreas secundarias (apoyo o genéricas).
• Contextos Delimitados (Bounded Contexts): Límites explícitos donde un modelo de dominio específico es válido. Define los límites de los módulos de software y suele ser la base para diseñar microservicios.

• Mapeo de Contextos (Context Mapping): Define cómo interactúan y se comunican los diferentes Contextos Delimitados entre sí (por ejemplo, como cliente/proveedor, o mediante un sistema de asociación).

  DDD tactico:

  Sus elementos principales son:

• Entidades (Entities): Objetos que se definen principalmente por su identidad única a lo largo del tiempo, más que por sus atributos (ej. un Usuario que cambia de dirección pero sigue siendo el mismo).

• Objetos de Valor (Value Objects): Objetos inmutables que describen características o atributos, pero no tienen una identidad conceptual propia (ej. Dirección o Precio).

• Agregados (Aggregates): Un clúster de Entidades y Objetos de Valor que se tratan como una sola unidad para garantizar la consistencia de los datos. Tienen una "Raíz del Agregado" que controla el acceso a todo el grupo.

• Repositorios (Repositories): Interfaces que gestionan el almacenamiento, recuperación y búsqueda de Agregados, ocultando los detalles de la base de datos.

• Servicios de Dominio (Domain Services): Operaciones o lógica de negocio que no encajan de forma natural dentro de una Entidad o un Objeto de Valor.

• Eventos de Dominio (Domain Events): Acciones que ocurren en el dominio y que son de interés para otros elementos del mismo sistema o para otros microservicios.

En resumen: El DDD estratégico te dice dónde dividir tu sistema y cómo organizar a tus equipos; el DDD táctico te dice cómo escribir el código y estructurar las clases para resolver la lógica de negocio real.

• Símil: Un sastre que construye una prenda a la medida exacta, de las necesidades del cliente, no un traje estándar.
• Ventajas: El código refleja fielmente la realidad de la empresa.
• Desventajas: Curva de aprendizaje alta.

Patrón Outbox

Concepto: Un patrón de mensajería que resuelve el problema de la "Doble Escritura" (escribir en la DB y enviar un mensaje simultáneamente). El evento se guarda en una tabla persistente dentro de la misma transacción de base de datos que el cambio principal. Un proceso posterior (o el mismo middleware) lee de esta tabla y asegura que el mensaje se publique en el bus de datos al menos una vez, garantizando la consistencia eventual entre sistemas.

• Símil: El buzón de salida de una oficina, en el cual dejas la carta y sabes que el cartero la recogerá, pero tu tarea de "enviar" ya está registrada.
• Ventajas: Consistencia garantizada entre DB y Mensajería.
• Desventajas: Requiere persistencia adicional para la tabla de salida.

Patron Inbox

Concepto: Un mecanismo de seguridad en el receptor de mensajes que registra cada ID de mensaje entrante en una tabla antes de procesarlo. Si el sistema intenta entregar el mismo mensaje nuevamente (debido a un reintento de red o fallo previo), el receptor verifica su "Inbox" y omite el procesamiento si el mensaje ya fue ejecutado. Esto garantiza que las acciones sean "Idempotentes" (ejecutarlas muchas veces tiene el mismo efecto que una sola).

• Símil: Una secretaria anotando llamadas en un cuaderno antes de pasarlas, si se pierde la línea, el registro persiste.
• Ventajas: Tolerancia a fallos y evita procesar mensajes duplicados.
• Desventajas: Aumento de almacenamiento en la DB.

Sagas

Concepto: Un patrón para gestionar transacciones de larga duración o flujos de trabajo que involucran múltiples contextos o servicios independientes. Dado que no se pueden usar transacciones globales en sistemas distribuidos o modulares, la Saga coordina una secuencia de pasos. Si un paso falla, la Saga ejecuta "Transacciones de Compensación" (acciones para deshacer o mitigar los efectos de los pasos anteriores), manteniendo el sistema en un estado consistente.

• Símil: Al reservar un viaje, si reservas el vuelo pero la reserva del hotel falla, la Saga cancela automáticamente el vuelo.
• Ventajas: Consistencia en sistemas distribuidos sin bloqueos de base de datos.
• Desventajas: Difícil de depurar y diseñar.

Trabajo en progreso 🚧👷🏽