Screaming Architecture는 유명한 소프트웨어 개발자이자 사상가인 Robert C. Martin(종종 "밥 삼촌"이라고도 함)이 도입한 개념입니다. 이 용어는 독특하게 들릴 수도 있지만, 시스템 아키텍처가 애플리케이션의 주요 관심사와 사용 사례를 반영하도록 만드는 데 중점을 두는 소프트웨어 설계의 강력한 원칙을 나타냅니다. 간단히 말해서, 소프트웨어 아키텍처는 의도와 목적을 "고명"해야 합니다.

이 종합 가이드에서는 Screaming Architecture의 기본 사항, 기존 소프트웨어 아키텍처와의 차이점, 도메인 중심 설계에서의 중요성, 프로젝트에서 이 아키텍처를 구현하는 방법을 살펴보겠습니다. 또한 Screaming Architecture가 코드 가독성, 유지 관리성 및 장기 확장성을 향상시킬 수 있는 실제 사례와 시나리오도 다룰 것입니다.

왜 "비명을 지르는" 아키텍처인가?

Screaming Architecture의 기본 아이디어는 코드베이스의 기본 구조가 비즈니스 목적을 즉시 전달해야 한다는 것입니다. 이는 기술 프레임워크, 도구 또는 기타 부차적인 관심사를 강조할 수 있는 기존 아키텍처와 대조됩니다. Screaming Architecture에서는 도메인 문제가 구현 세부 사항보다 우선합니다.

밥 마틴 삼촌은 이것을 비유로 설명했습니다. 건물에 다가가 그 건축물을 보는 것을 상상해 보십시오. 간판이 없어도 도서관인지, 학교인지, 사무실인지 알 수 있는 경우가 많습니다. 소프트웨어 아키텍처에도 동일하게 적용되어야 합니다. 애플리케이션의 폴더 구조와 디자인을 보면 그것이 무엇을 위한 것인지 즉시 이해해야 합니다. 회계 시스템을 구축하는 경우 아키텍처는 "Django", "Spring Boot" 또는 "React"가 아닌 "회계"를 외쳐야 합니다.

프레임워크 중심 아키텍처의 문제점

많은 프로젝트에서 기술 프레임워크에 대한 초점이 비즈니스 또는 도메인 논리를 무색하게 만듭니다. 다음과 같은 파일 구조를 찾을 수 있습니다:

controllers/

services/

repositories/

models/

이러한 디렉토리는 유용하지만 소프트웨어가 해결하는 핵심 문제를 반영하기보다는 기술적인 역할을 설명합니다. 예를 들어 이 구조는 시스템이 MVC(Model-View-Controller)를 사용한다는 것을 알려주지만 시스템이 재무 데이터, 사용자 관리 또는 콘텐츠 생성을 처리하는지 여부에 대한 통찰력은 제공하지 않습니다.

프레임워크 함정

프레임워크를 지나치게 강조하면 기술 상용구로 인해 비즈니스 논리가 모호해지는 코드베이스가 생성됩니다. 프레임워크 규칙을 중심으로 구축된 시스템은 해당 프레임워크와 긴밀하게 결합됩니다. 프레임워크나 기술 스택을 변경하려는 경우 리팩토링이 큰 노력이 됩니다. Screaming Architecture는 도메인 로직을 깔끔하고 분리된 상태로 유지하는 것을 옹호하므로 프레임워크 선택은 코드베이스의 핵심 구조가 아닌 구현 세부 사항이 됩니다.

도메인 중심 설계(DDD)의 비명을 지르는 아키텍처

DDD(Domain-Driven Design)와 Screaming Architecture는 종종 함께 사용됩니다. DDD는 기술 전문가와 도메인 전문가 간의 협업을 강조하는 소프트웨어 개발 접근 방식으로, 실제 운영과 밀접하게 일치하는 방식으로 핵심 비즈니스 로직을 모델링하는 데 중점을 둡니다.

Screaming Architecture에서는 도메인 모델과 비즈니스 로직이 애플리케이션의 중심에 있고 프레임워크, 데이터베이스, UI, 서비스 등 다른 모든 것이 주변 장치가 됩니다. 핵심 아이디어는 코드 구조가 기술적 구현 세부 사항보다는 도메인 모델을 반영해야 한다는 것입니다.

도메인 기반 원칙을 사용하여 의도를 "비명"하는 방식으로 프로젝트를 구성하는 방법은 다음과 같습니다.

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

이 예에서 폴더 이름은 회계 및 판매와 같은 비즈니스 문제를 직접적으로 반영합니다. Ledger, Transaction 및 Order와 같은 각 도메인별 클래스는 관련 도메인 컨텍스트 내에 배치됩니다. 이 구조를 통해 시스템이 무엇인지, 각 구성 요소가 어디에 적합한지 즉시 알 수 있습니다.

코드 예제 1: 간단한 도메인 중심 구조

주문과 재고를 처리하는 전자상거래 애플리케이션을 생각해 보세요. Screaming Architecture를 사용하면 폴더 구조는 기술적인 역할보다는 비즈니스 로직을 반영해야 합니다.

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

다음은 주문 컨텍스트의 기본 코드 예시입니다.

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; }
}

이 코드에서는 도메인 개념(Order)이 전면 중앙에 있으며 OrderService 및 OrderRepository와 같은 지원 논리는 별도의 파일에 보관됩니다. 비즈니스 로직(CalculateTotal)은 서비스나 컨트롤러에 숨겨져 있는 것이 아니라 Order 엔터티의 일부입니다.

기술적 방해 요소 방지

프레임워크와 라이브러리는 소프트웨어 개발에 매우 ​​중요하지만 비즈니스 로직의 구조를 결정해서는 안 됩니다. Screaming Architecture는 HTTP 컨트롤러, 지속성 레이어, 데이터베이스 프레임워크와 같은 기술적 세부 사항을 주변 장치로 푸시하는 것을 옹호합니다.

다음은 전통적 아키텍처와 놀라운 아키텍처를 대조하는 예입니다.

전통 건축:

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

이것은 기술적으로 정확하지만 시스템의 용도를 알려주지는 않습니다. 폴더 구조는 도메인에 대해 아무 것도 나타내지 않습니다. 전자상거래 시스템인가요? 금융 신청? 코드를 자세히 살펴보지 않고는 알 수 없습니다.

비명을 지르는 아키텍처:

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

이 구조는 시스템이 주문과 재고를 처리한다는 것을 즉시 명확하게 보여줍니다. 나중에 더 많은 도메인(예: 고객, 결제)을 추가하면 아키텍처에서 전용 위치를 갖게 됩니다.

클린건축의 역할

Screaming Architecture는 종종 Uncle Bob의 더 넓은 Clean Architecture 원칙과 일치합니다. 클린 아키텍처는 비즈니스 규칙이 프레임워크, UI 및 데이터베이스로부터 독립되도록 보장하는 데 중점을 두고 우려사항의 분리를 촉진합니다. Screaming Architecture는 프로젝트 구조가 핵심 비즈니스 로직을 드러내야 한다고 제안함으로써 이를 한 단계 더 발전시킵니다.

클린 아키텍처에 대한 간략한 요약은 다음과 같습니다.

엔터티: 핵심 비즈니스 개체 및 논리.

사용 사례: 애플리케이션별 비즈니스 규칙.

인터페이스: 프레임워크 및 외부 시스템용 게이트웨이.

프레임워크 및 드라이버: UI, 데이터베이스 및 기타 외부 구성 요소.

클린 아키텍처 프로젝트에서 주문, 고객, 송장과 같은 도메인 개념은 중앙 레이어의 일부입니다. ASP.NET Core, Django 또는 Rails와 같은 프레임워크는 외부 계층으로 이관되어 핵심 기능을 제공하는 메커니즘 역할을 합니다.

코드 예제 2: Screaming Architecture에 클린 아키텍처 적용

Screaming Architecture에서는 비즈니스 도메인을 반영하는 방식으로 사용 사례와 엔터티를 구성합니다. 전자상거래 예시를 확장해 보겠습니다.

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

다음은 주문 생성에 대한 예시 사용 사례입니다.

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;
    }
}

이 예에서 CreateOrderUseCase는 도메인 로직의 일부이며 OrderRepository 및 InventoryService와 상호 작용하여 주문 생성에 대한 비즈니스 요구 사항을 충족합니다.

Screaming Architecture의 이점

가독성 향상: 코드베이스를 여는 사람은 누구나 시스템이 수행하는 작업을 즉시 이해할 수 있습니다.

관심의 분리: 비즈니스 로직이 기술적 세부 사항과 분리되어 있으므로 나중에 프레임워크나 기술을 더 쉽게 변경할 수 있습니다.

확장성: 시스템이 성장함에 따라 도메인 구조가 일관되게 유지되므로 새로운 기능과 모듈을 쉽게 추가할 수 있습니다.

유지관리성: 도메인 로직이 외부 종속성 및 프레임워크와 완전히 분리되면 유지 관리가 더 쉽습니다.

프레임워크 불가지론: Screaming Architecture를 사용하면 비즈니스 로직이 특정 프레임워크와의 긴밀한 결합을 피하면서 다양한 기술 스택 간에 이식성을 유지할 수 있습니다.

비명을 지르는 건축에 대한 비판

Screaming Architecture에는 많은 이점이 있지만 비판도 있습니다.

인식된 복잡성: 도메인 기반 설계에 익숙하지 않은 개발자는 소규모 애플리케이션의 경우 도메인 로직과 기술 세부 사항의 분리가 불필요하거나 지나치게 복잡하다고 생각할 수 있습니다.
2

. 오버헤드: 소규모 프로젝트나 간단한 CRUD 애플리케이션에서는 Screaming Architecture를 구현하는 것이 과도한 것처럼 보일 수 있습니다.

학습 곡선: 프레임워크 우선 접근 방식에 익숙한 팀의 경우 Screaming Architecture를 채택하려면 사고의 전환이 필요하며 이를 내면화하는 데 시간이 걸릴 수 있습니다.

스크리밍 아키텍처를 사용해야 하는 경우

Screaming Architecture는 다음 시나리오에서 특히 유용합니다.

도메인 기반 시스템: 복잡한 비즈니스 규칙과 도메인 논리가 포함된 애플리케이션.

장기 프로젝트: 확장성과 유지 관리성이 중요한 시간이 지남에 따라 발전할 것으로 예상되는 시스템입니다.

교차 플랫폼 개발: 프레임워크나 플랫폼을 전환할 수 있는 시스템으로 비즈니스 로직을 깔끔하게 분리하는 것이 필수적입니다.

결론

Screaming Architecture는 단순한 이름 그 이상입니다. 핵심 비즈니스 로직을 코드베이스에서 가장 눈에 띄는 부분으로 만드는 것을 옹호하는 철학입니다. 개발자는 기술 프레임워크보다는 도메인 개념에 초점을 맞춤으로써 장기적으로 더 읽기 쉽고 유지 관리가 가능하며 확장 가능한 시스템을 구축할 수 있습니다. 간단한 웹 애플리케이션에서 작업하든 복잡한 엔터프라이즈 시스템에서 작업하든 Screaming Architecture를 채택하면 목적을 명확하게 표현하는 더욱 깔끔하고 집중된 코드를 얻을 수 있습니다.

Screaming Architecture에 대해 자세히 알아보려면 다음 참고 자료와 추가 자료를 확인하세요.

클린 아키텍처 - 로버트 C. 마틴(Robert C. Martin)

Eric Evans의 도메인 기반 디자인

클린 코드에 관한 Bob 삼촌의 블로그

Screaming Architecture의 원칙을 수용함으로써 작동할 뿐만 아니라 의도를 "비명"하는 코드베이스를 만들 수 있습니다.