Кричащая архитектура — это концепция, представленная известным разработчиком программного обеспечения и идейным лидером Робертом К. Мартином, которого часто называют «дядей Бобом». Этот термин может показаться нетрадиционным, но он представляет собой мощный принцип проектирования программного обеспечения, направленный на то, чтобы архитектура системы отражала основные задачи и варианты использования приложения. Проще говоря, архитектура вашего программного обеспечения должна «кричать» о его намерениях и целях.

В этом подробном руководстве мы рассмотрим основы кричащей архитектуры, ее отличие от традиционной архитектуры программного обеспечения, ее значение в предметно-ориентированном проектировании и то, как вы можете реализовать эту архитектуру в своих проектах. Мы также рассмотрим практические примеры и сценарии, в которых кричащая архитектура может улучшить читаемость кода, удобство сопровождения и долгосрочную масштабируемость.

Почему «кричащая» архитектура?

Идея Screaming Architecture заключается в том, что основная структура вашей кодовой базы должна сразу отражать ее бизнес-цели. Это контрастирует с традиционными архитектурами, в которых упор делается на технические структуры, инструменты или другие второстепенные задачи. В Screaming Architecture проблемы предметной области имеют приоритет над деталями реализации.

Дядя Боб Мартин проиллюстрировал это аналогией: представьте, что вы подходите к зданию и видите его архитектуру. Без необходимости вывески часто можно определить, библиотека ли это, школа или офис. То же самое должно относиться и к архитектуре программного обеспечения. Когда вы посмотрите на структуру папок и дизайн приложения, вы сразу поймете, для чего оно нужно. Если вы создаете систему учета, архитектура должна кричать «учет», а не «Django», «Spring Boot» или «React».

Проблемы фреймворкоцентрической архитектуры

Во многих проектах акцент на технологических платформах затмевает бизнес-логику или логику предметной области. Вы найдете такие файловые структуры, как:

controllers/

services/

repositories/

models/

Хотя эти каталоги полезны, они описывают технические роли, а не отражают основную проблему, которую решает программное обеспечение. Например, эта структура сообщает вам, что система использует MVC (модель-представление-контроллер), но не дает представления о том, обрабатывает ли система финансовые данные, управление пользователями или создание контента.

Ловушка фреймворка

Чрезмерный акцент на фреймворках приводит к тому, что в базах кода бизнес-логика скрыта техническим шаблоном. Система, построенная на основе соглашений о фреймворках, становится тесно связанной с этими фреймворками. Если вы когда-нибудь захотите изменить структуру или стеки технологий, рефакторинг станет серьезным усилием. Screaming Architecture выступает за то, чтобы логика вашей предметной области была чистой и отдельной, поэтому выбор платформы становится деталью реализации, а не основной структурой вашей кодовой базы.

Кричащая архитектура в предметно-ориентированном проектировании (DDD)

Domain-Driven Design (DDD) и кричащая архитектура часто идут рука об руку. DDD — это подход к разработке программного обеспечения, в котором упор делается на сотрудничество между техническими экспертами и экспертами в предметной области, а также на моделировании основной бизнес-логики таким образом, чтобы она тесно соответствовала реальным операциям.

В Screaming Architecture модель предметной области и бизнес-логика находятся в центре приложения, а все остальное — платформы, базы данных, пользовательский интерфейс и сервисы — становится второстепенным. Основная идея заключается в том, что структура кода должна отражать модель предметной области, а не детали технической реализации.

Вот как вы можете структурировать свой проект таким образом, чтобы он «кричал» о своих намерениях, используя принципы, ориентированные на предметную область:

/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 идет еще дальше, предлагая, чтобы структура проекта раскрывала основную бизнес-логику.

Вот краткий обзор чистой архитектуры:

Сущности: основные бизнес-объекты и логика.

Случаи использования: бизнес-правила для конкретных приложений.

Интерфейсы: шлюзы для фреймворков и внешних систем.

Фреймворки и драйверы: пользовательский интерфейс, базы данных и другие внешние компоненты.

В проекте «Чистая архитектура» такие понятия предметной области, как «Заказ», «Клиент» и «Счет-фактура», являются частью центрального уровня. Такие платформы, как ASP.NET Core, Django или Rails, отнесены к внешним уровням и служат механизмами для реализации основных функций.

Пример кода 2: применение чистой архитектуры в кричащей архитектуре

В кричащей архитектуре вы должны структурировать варианты использования и сущности таким образом, чтобы они отражали сферу бизнеса. Давайте расширим наш пример электронной коммерции:

/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 позволяет бизнес-логике оставаться переносимой между различными техническими стеками, избегая жесткой связи с какой-либо конкретной инфраструктурой.

Критика кричащей архитектуры

Хотя кричащая архитектура имеет множество преимуществ, она не лишена критики:

Ощущаемая сложность: разработчики, незнакомые с проектированием на основе предметной области, могут счесть отделение логики предметной области от технических деталей ненужным или слишком сложным для небольших приложений.
2

. Накладные расходы: в небольших проектах или простых CRUD-приложениях реализация Screaming Architecture может показаться излишним.

Кривая обучения: для команд, привыкших к подходам, ориентированным на структуру, внедрение кричащей архитектуры требует изменения в мышлении, для усвоения которого может потребоваться время.

Когда использовать кричащую архитектуру

Кричащая архитектура особенно полезна в следующих сценариях:

Системы, управляемые предметной областью: приложения со сложными бизнес-правилами и логикой предметной области.

Долгосрочные проекты: ожидается, что системы будут развиваться с течением времени, где масштабируемость и удобство обслуживания имеют решающее значение.

Кроссплатформенная разработка: системы, которые могут переключать платформы или платформы, что делает необходимым четкое разделение бизнес-логики.

Заключение

Кричащая архитектура — это больше, чем просто запоминающееся название; это философия, которая призывает сделать основную бизнес-логику наиболее заметной частью вашей кодовой базы. Сосредоточив внимание на концепциях предметной области, а не на технических структурах, разработчики могут создавать системы, которые будут более читабельными, удобными в обслуживании и масштабируемыми в долгосрочной перспективе. Независимо от того, работаете ли вы над простым веб-приложением или сложной корпоративной системой, внедрение Screaming Architecture может привести к созданию более чистого и целенаправленного кода, который четко выражает свою цель.

Чтобы узнать больше о кричащей архитектуре, вы можете просмотреть некоторые ссылки и дополнительную литературу:

Чистая архитектура Роберта К. Мартина

Дизайн, ориентированный на предметную область, Эрик Эванс

Блог дяди Боба о чистом коде

Приняв принципы кричащей архитектуры, вы можете создавать базы кода, которые не только работают, но и «кричат» о своих намерениях.