Screaming Architecture es un concepto introducido por el renombrado desarrollador de software y líder intelectual Robert C. Martin, a menudo denominado "Tío Bob". El término puede parecer poco convencional, pero representa un principio poderoso en el diseño de software, que se centra en hacer que la arquitectura de un sistema refleje las principales preocupaciones y casos de uso de la aplicación. En términos más simples, la arquitectura de su software debe "gritar" su intención y propósito.

En esta guía completa, exploraremos los fundamentos de Screaming Architecture, cómo contrasta con la arquitectura de software tradicional, su importancia en el diseño basado en dominios y cómo puede implementar esta arquitectura en sus proyectos. También cubriremos ejemplos y escenarios prácticos en los que Screaming Architecture puede mejorar la legibilidad, el mantenimiento y la escalabilidad a largo plazo del código.

¿Por qué arquitectura "gritando"?

La idea detrás de Screaming Architecture es que la estructura primaria de su código base debe transmitir inmediatamente su propósito comercial. Esto contrasta con las arquitecturas tradicionales, que podrían enfatizar marcos técnicos, herramientas u otras preocupaciones secundarias. En Screaming Architecture, las preocupaciones sobre el dominio tienen prioridad sobre los detalles de implementación.

El tío Bob Martin ilustró esto con una analogía: imagina caminar hasta un edificio y ver su arquitectura. Sin necesidad de un letrero, a menudo se puede saber si se trata de una biblioteca, una escuela o una oficina. Lo mismo debería aplicarse a la arquitectura del software. Cuando observa la estructura de carpetas y el diseño de una aplicación, debe comprender inmediatamente para qué sirve. Si estás creando un sistema de contabilidad, la arquitectura debería gritar "contabilidad", no "Django", "Spring Boot" o "React".

Los problemas con la arquitectura centrada en el framework

En muchos proyectos, el enfoque en los marcos tecnológicos eclipsa la lógica empresarial o de dominio. Encontrarás estructuras de archivos como:

controllers/

services/

repositories/

models/

Si bien estos directorios son útiles, describen funciones técnicas en lugar de reflejar el problema central que resuelve el software. Por ejemplo, esta estructura le indica que el sistema utiliza MVC (Modelo-Vista-Controlador) pero no proporciona información sobre si el sistema maneja datos financieros, administración de usuarios o creación de contenido.

La trampa del marco

El énfasis excesivo en los marcos da como resultado bases de código donde la lógica empresarial queda oscurecida por textos técnicos repetitivos. Un sistema construido alrededor de convenciones marco se acopla estrechamente a esos marcos. Si alguna vez desea cambiar los marcos o las pilas de tecnología, la refactorización se convierte en un esfuerzo importante. Screaming Architecture aboga por mantener la lógica de su dominio limpia y separada, por lo que la elección del marco se convierte en un detalle de implementación en lugar de la estructura central de su código base.

Arquitectura gritante en diseño basado en dominios (DDD)

El diseño basado en dominios (DDD) y la arquitectura Screaming a menudo van de la mano. DDD es un enfoque para el desarrollo de software que enfatiza la colaboración entre expertos técnicos y de dominio, y se enfoca en modelar la lógica empresarial central de una manera que se alinea estrechamente con las operaciones del mundo real.

En Screaming Architecture, el modelo de dominio y la lógica empresarial están en el centro de la aplicación, y todo lo demás (marcos, bases de datos, interfaz de usuario y servicios) se vuelve periférico. La idea clave es que la estructura del código debe reflejar el modelo de dominio en lugar de los detalles técnicos de implementación.

A continuación te explicamos cómo puedes estructurar tu proyecto de una manera que "grite" su intención utilizando principios basados ​​en el dominio:

/src
    /accounting
        Ledger.cs
        Transaction.cs
        Account.cs
        TaxService.cs
    /sales
        Order.cs
        Invoice.cs
        Customer.cs
        DiscountPolicy.cs

En este ejemplo, los nombres de las carpetas reflejan directamente las preocupaciones comerciales: contabilidad y ventas. Cada clase específica de dominio, como Libro mayor, Transacción y Orden, se coloca dentro de su contexto de dominio relevante. Esta estructura deja claro de inmediato de qué se trata el sistema y dónde encaja cada componente.

Ejemplo de código 1: una estructura simple centrada en el dominio

Considere una aplicación de comercio electrónico que maneje pedidos e inventario. Con Screaming Architecture, la estructura de carpetas debe reflejar la lógica empresarial en lugar de los roles técnicos:

/src
    /orders
        Order.cs
        OrderService.cs
        OrderRepository.cs
    /inventory
        InventoryItem.cs
        InventoryService.cs
        InventoryRepository.cs

Aquí hay un ejemplo de código básico del contexto de pedidos:

public class Order
{
    public Guid Id { get; set; }
    public DateTime OrderDate { get; set; }
    public List Items { get; set; }
    public decimal TotalAmount { get; set; }

    public Order(List items)
    {
        Id = Guid.NewGuid();
        OrderDate = DateTime.Now;
        Items = items;
        TotalAmount = CalculateTotal(items);
    }

    private decimal CalculateTotal(List items)
    {
        return items.Sum(item => item.Price * item.Quantity);
    }
}

public class OrderItem
{
    public string ProductName { get; set; }
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}

En este código, el concepto de dominio (Order) está al frente y al centro, con una lógica de soporte como OrderService y OrderRepository guardadas en archivos separados. La lógica de negocios (CalculateTotal) es parte de la entidad Order, en lugar de estar oculta en un servicio o controlador.

Evitar distracciones técnicas

Los marcos y las bibliotecas son cruciales para el desarrollo de software, pero no deberían dictar cómo se estructura la lógica empresarial. Screaming Architecture aboga por llevar los detalles técnicos como controladores HTTP, capas de persistencia y marcos de bases de datos a la periferia.

Aquí hay un ejemplo que contrasta las arquitecturas tradicionales y llamativas:

Arquitectura Tradicional:

/src
    /controllers
        OrderController.cs
    /services
        OrderService.cs
    /repositories
        OrderRepository.cs
    /models
        Order.cs
        OrderItem.cs

Si bien esto es técnicamente correcto, no indica para qué sirve el sistema. La estructura de carpetas no revela nada sobre el dominio. ¿Es un sistema de comercio electrónico? ¿Una aplicación financiera? Es imposible saberlo sin profundizar en el código.

Arquitectura que grita:

/src
    /orders
        OrderController.cs
        OrderService.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        InventoryController.cs
        InventoryService.cs
        InventoryRepository.cs
        InventoryItem.cs

Esta estructura aclara inmediatamente que el sistema maneja pedidos e inventario. Si agrega más dominios en el futuro (por ejemplo, clientes, pagos), tendrán un lugar dedicado en la arquitectura.

El papel de la arquitectura limpia

Screaming Architecture a menudo se alinea con los principios más amplios de Clean Architecture del tío Bob. Clean Architecture promueve una separación de preocupaciones, enfocándose en garantizar que las reglas comerciales sean independientes de los marcos, la interfaz de usuario y las bases de datos. Screaming Architecture va un paso más allá al sugerir que la estructura del proyecto debería revelar la lógica empresarial central.

Aquí hay un resumen rápido de Arquitectura Limpia:

Entidades: lógica y objetos comerciales centrales.

Casos de uso: reglas comerciales específicas de la aplicación.

Interfaces: Puertas de enlace para frameworks y sistemas externos.

Marcos y controladores: interfaz de usuario, bases de datos y otros componentes externos.

En un proyecto de Arquitectura Limpia, conceptos de dominio como Pedido, Cliente y Factura son parte de la capa central. Los marcos como ASP.NET Core, Django o Rails quedan relegados a las capas externas, sirviendo como mecanismos para ofrecer la funcionalidad principal.

Ejemplo de código 2: Aplicación de arquitectura limpia en arquitectura Screaming

En una arquitectura Screaming, estructurarías los casos de uso y las entidades de una manera que refleje el dominio empresarial. Ampliemos nuestro ejemplo de comercio electrónico:

/src
    /orders
        CreateOrderUseCase.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        AddInventoryItemUseCase.cs
        InventoryRepository.cs
        InventoryItem.cs

A continuación se muestra un caso de uso de ejemplo para crear un pedido:

public class CreateOrderUseCase
{
    private readonly IOrderRepository _orderRepository;
    private readonly IInventoryService _inventoryService;

    public CreateOrderUseCase(IOrderRepository orderRepository, IInventoryService inventoryService)
    {
        _orderRepository = orderRepository;
        _inventoryService = inventoryService;
    }

    public Order Execute(List items)
    {
        // Ensure all items are available in inventory
        foreach (var item in items)
        {
            _inventoryService.CheckInventory(item.ProductName, item.Quantity);
        }

        var order = new Order(items);
        _orderRepository.Save(order);
        return order;
    }
}

En este ejemplo, CreateOrderUseCase es parte de la lógica del dominio e interactúa con OrderRepository e InventoryService para satisfacer la necesidad comercial de crear un pedido.

Beneficios de la arquitectura Screaming

Legibilidad mejorada: cualquiera que abra su código base comprenderá inmediatamente lo que hace el sistema.

Separación de preocupaciones: la lógica empresarial permanece aislada de los detalles técnicos, lo que facilita el cambio de marcos o tecnologías más adelante.

Escalabilidad: a medida que el sistema crece, la estructura del dominio permanece consistente, lo que permite agregar fácilmente nuevas funciones y módulos.

Mantenibilidad: la lógica del dominio es más fácil de mantener cuando está claramente separada de las dependencias y marcos externos.

Agnóstico del marco: Screaming Architecture permite que la lógica empresarial siga siendo portátil entre diferentes pilas técnicas, evitando un acoplamiento estrecho con cualquier marco en particular.

Críticas a la arquitectura del grito

Si bien Screaming Architecture tiene muchos beneficios, no está exento de críticas:

Complejidad percibida: los desarrolladores que no están familiarizados con el diseño basado en dominios pueden encontrar la separación de la lógica del dominio de los detalles técnicos innecesaria o demasiado compleja para aplicaciones pequeñas.
2

. General: en proyectos pequeños o aplicaciones CRUD simples, implementar Screaming Architecture puede parecer excesivo.

Curva de aprendizaje: para los equipos acostumbrados a enfoques que priorizan el marco, adoptar Screaming Architecture requiere un cambio de pensamiento que puede llevar tiempo internalizar.

Cuándo utilizar la arquitectura Screaming

Screaming Architecture es particularmente útil en los siguientes escenarios:

Sistemas controlados por dominio: aplicaciones con reglas comerciales y lógica de dominio complejas.

Proyectos a largo plazo: Se espera que los sistemas evolucionen con el tiempo, donde la escalabilidad y la mantenibilidad son críticas.

Desarrollo multiplataforma: sistemas que pueden cambiar de marco o plataforma, lo que hace esencial una separación clara de la lógica empresarial.

Conclusión

Screaming Architecture es más que un simple nombre pegadizo; es una filosofía que aboga por hacer de la lógica empresarial central la parte más destacada de su código base. Al centrarse en conceptos de dominio en lugar de marcos técnicos, los desarrolladores pueden crear sistemas que sean más legibles, mantenibles y escalables a largo plazo. Ya sea que esté trabajando en una aplicación web simple o en un sistema empresarial complejo, adoptar Screaming Architecture puede generar un código más limpio y enfocado que exprese claramente su propósito.

Para obtener más información sobre Screaming Architecture, puedes consultar algunas referencias y lecturas adicionales:

Arquitectura limpia por Robert C. Martin

Diseño basado en dominios por Eric Evans

Blog del tío Bob sobre código limpio

Al adoptar los principios de Screaming Architecture, puedes crear bases de código que no solo funcionan sino que también "gritan" su intención.