스크리밍 아키텍처란 무엇인가?

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

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

왜 "비명을 지르는" 건축인가?

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

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

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

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

controllers/

services/

repositories/

models/

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

프레임워크 함정

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

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

도메인 기반 디자인(DDD)과 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<OrderItem> Items { get; set; }
    public decimal TotalAmount { get; set; }

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

    private decimal CalculateTotal(List<OrderItem> 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 엔터티의 일부입니다.

기술적 방해 요소 방지

Frameworks and libraries are crucial for software development, but they shouldn't dictate how your business logic is structured. Screaming Architecture advocates for pushing technical details like HTTP controllers, persistence layers, and database frameworks to the periphery.

Here’s an example that contrasts the traditional and screaming architectures:

Traditional Architecture:

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

While this is technically correct, it doesn’t tell you what the system is for. The folder structure reveals nothing about the domain. Is it an e-commerce system? A financial application? It’s impossible to know without diving deep into the code.

Screaming Architecture:

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

This structure immediately clarifies that the system handles orders and inventory. If you add more domains in the future (e.g., customers, payments), they’ll have a dedicated place in the architecture.

The Role of Clean Architecture

Screaming Architecture often aligns with Uncle Bob’s broader Clean Architecture principles. Clean Architecture promotes a separation of concerns, focusing on ensuring that business rules are independent of frameworks, UI, and databases. Screaming Architecture takes this a step further by suggesting that the project’s structure should reveal the core business logic.

Here’s a quick recap of Clean Architecture:

Entities: Core business objects and logic.

Use Cases: Application-specific business rules.

Interfaces: Gateways for frameworks and external systems.

Frameworks & Drivers: UI, databases, and other external components.

In a Clean Architecture project, domain concepts like Order, Customer, and Invoice are part of the central layer. Frameworks like ASP.NET Core, Django, or Rails are relegated to the outer layers, serving as mechanisms to deliver the core functionality.

Code Example 2: Applying Clean Architecture in Screaming Architecture

In a Screaming Architecture, you’d structure the use cases and entities in a way that reflects the business domain. Let’s extend our e-commerce example:

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

Here’s an example use case for creating an order:

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

In this example, the CreateOrderUseCase is part of the domain logic and interacts with the OrderRepository and InventoryService to fulfill the business need of creating an order.

Benefits of Screaming Architecture

Improved Readability: Anyone who opens your codebase will immediately understand what the system does.

Separation of Concerns: Business logic remains isolated from technical details, making it easier to change frameworks or technologies later.

Scalability: As the system grows, the domain structure remains consistent, allowing for easy addition of new features and modules.

Maintainability: Domain logic is easier to maintain when it’s cleanly separated from external dependencies and frameworks.

Framework Agnostic: Screaming Architecture allows the business logic to remain portable across different technical stacks, avoiding tight coupling with any particular framework.

Criticisms of Screaming Architecture

While Screaming Architecture has many benefits, it’s not without its criticisms:

Perceived Complexity: Developers unfamiliar with domain-driven design may find the separation of domain logic from technical details unnecessary or overly complex for small applications.
2

. Overhead: In small projects or simple CRUD applications, implementing Screaming Architecture may seem like overkill.

Learning Curve: For teams used to framework-first approaches, adopting Screaming Architecture requires a shift in thinking that may take time to internalize.

When to Use Screaming Architecture

Screaming Architecture is particularly useful in the following scenarios:

Domain-Driven Systems: Applications with complex business rules and domain logic.

Long-Term Projects: Systems expected to evolve over time, where scalability and maintainability are critical.

Cross-Platform Development: Systems that may switch frameworks or platforms, making a clean separation of business logic essential.

Conclusion

Screaming Architecture is more than just a catchy name; it’s a philosophy that advocates for making the core business logic the most prominent part of your codebase. By focusing on domain concepts rather than technical frameworks, developers can build systems that are more readable, maintainable, and scalable in the long run. Whether you’re working on a simple web application or a complex enterprise system, adopting Screaming Architecture can lead to cleaner, more focused code that clearly expresses its purpose.

To learn more about Screaming Architecture, you can check out some references and additional readings:

Architecture propre par Robert C. Martin

Conception basée sur le domaine par Eric Evans

Le blog de l'oncle Bob sur le code propre

En adoptant les principes de Screaming Architecture, vous pouvez créer des bases de code qui non seulement fonctionnent, mais qui « crient » également leur intention.

위 내용은 스크리밍 아키텍처란 무엇인가?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!