Architecture

...читать Eric Evans’s Domain-Driven Design or Martin Fowler’s Patterns of Enterprise Application Architecture

1. Архитектуры по "форме" приложения

Это структурные стили — описывают, как приложение разделено на части и как они взаимодействуют.

Эти стили можно комбинировать: например, может быть Hexagonal Monolith, который внутри реализует MVC.

2. Архитектуры по распределению

Описывают взаимодействие между узлами в распределённой системе.

• Client–Server — базовый шаблон,
• Microservices — его развитие (много серверов),
• P2P — противоположная модель (нет центрального узла).

3. Архитектуры по взаимодействию (коммуникации)

Описывают как компоненты обмениваются данными.

• CQRS и Event Sourcing часто идут в паре
• EDA и Pub/Sub — это механизмы коммуникации (Pub/Sub — частный случай EDA)

4. Архитектуры по проектированию домена

Они определяют как организовать бизнес-логику.

DDD часто комбинируется с Hexagonal, CQRS, Event Sourcing.

Итого: визуальная группировка

Пример сочетания в реальной системе заказов:

• Архитектура: Hexagonal + DDD
• Взаимодействие между сервисами: Event-Driven (Kafka)
• Каждый сервис: CQRS + Event Sourcing
• Разделение сервисов: Microservices
• UI: MVC во фронтенде
• Общая форма деплоя: Client–Server

Architectural Styles

Monolithic

Монолитная архитектура (Monolithic)

• Суть: Вся система разрабатывается, развертывается и работает как единое целое. Компоненты тесно связаны и выполняются в одном процессе.
• Эксперимент: Сравнить классический многослойный монолит (Presentation-Business-Data layers) с модульным монолитом (Modular Monolith), где модули имеют строгие границы.

Messaging

Puplish-Subscribe

TODO: добавить больше информации, пример, пояснение

Event-Driven

Событийно-ориентированная архитектура (Event-Driven Architecture, EDA)

• Суть: Компоненты системы общаются путем асинхронной рассылки и обработки событий. Они слабо связаны и не знают друг о друге.
• Эксперимент: Спроектировать одну и ту же систему, используя EDA и более традиционный запросно-ответный стиль (например, REST), и сравнить производительность, отказоустойчивость и сложность.

TODO: добавить больше информации, пример, пояснение

Distributed

Client-Server

TODO: добавить больше информации, пример, пояснение

Peer-to-Peer

TODO: добавить больше информации, пример, пояснение

Архитектура "peer-to-peer" (P2P) представляет собой распределенную архитектурную модель, в которой каждый участник сети (пир) может одновременно выполнять роль как клиента, так и сервера. В такой сети нет центрального управляющего узла или сервера. Вместо этого каждый узел взаимодействует непосредственно с другими узлами, обмениваясь ресурсами, информацией или услугами.

Основные характеристики архитектуры P2P включают:

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

Равноправность (Peerness): Все участники сети называются "пирами". Каждый пир имеет равные права и обязанности.

Самоорганизация: Узлы сети самостоятельно принимают решения и координируют свою работу с другими узлами, обеспечивая эффективность и стабильность сети.

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

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

Примеры использования архитектуры P2P включают сети для обмена файлами (например, BitTorrent), блокчейн-технологии (например, Bitcoin), VoIP-телефонии (например, Skype) и децентрализованных приложений (DApps).

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

Architectural Pattern Model View Controller(MVC)

TODO: добавить больше информации, пример, пояснение

Architectural Pattern Microservices

Микросервисная архитектура (Microservices)

• Суть: Система разбивается на небольшие, слабо связанные сервисы, каждый из которых отвечает за свою бизнес-возможность. Сервисы развертываются независимо и общаются по сети.
• Эксперимент: Сравнить разные способы коммуникации (синхронный REST vs асинхронный messaging) или разные стратегии декомпозиции (по бизнес-возможностям vs по поддоменам DDD).

TODO: добавить больше информации, пример, пояснение

Architectural Pattern Event Sourcing

TODO: добавить больше информации, пример, пояснение

Architectural Pattern CQRS

CQRS (Command Query Responsibility Segregation) — это шаблон проектирования, предлагающий разделение команд (изменяющих данные) и запросов (читающих данные) в приложении.

Принцип Command-Query Separation (CQS) разделение команд-запросов «Функции не должны вызывать абстрактные побочные эффекты... только команды (процедуры) могут вызывать побочные эффекты». - Бертран Мейер: Объектно-ориентированное создание программного обеспечения.

CQS - "Метод должен либо изменять состояние объекта (команда), либо возвращать данные (запрос), но не делать оба действия одновременно."

CQS и CQRS — это разные, хотя и связанные концепции. CQS действует на уровне методов/обьектов для поддержания частоты кода и не нуждается в синхронизации данных так как все в одном объекте, а CQRS на архитектурном уровне всей системы для масштабируемости и требует явной синхронизации данных. CQS является основой для понимания CQRS, но они решают разные задачи на разных уровнях абстракции.

#![allow(unused)]
fn main() {
// CQRS - разные модели для команд и запросов

// МОДЕЛЬ КОМАНД (для записи)
struct BankAccountWrite {
    balance: f64,
}

impl BankAccountWrite {
    fn new() -> Self {
        Self { balance: 0.0 }
    }
    
    fn deposit(&mut self, amount: f64) {
        self.balance += amount;
        // Здесь может быть сложная бизнес-логика
    }
    
    fn withdraw(&mut self, amount: f64) -> Result<(), String> {
        if amount > self.balance {
            return Err("Insufficient funds".to_string());
        }
        self.balance -= amount;
        Ok(())
    }
}

// МОДЕЛЬ ЗАПРОСОВ (для чтения)
struct BankAccountRead {
    account_id: u64,
    balance: f64,
    last_transactions: Vec<Transaction>,
}

impl BankAccountRead {
    fn get_balance(&self) -> f64 {
        self.balance
    }
    
    fn get_transaction_history(&self) -> &[Transaction] {
        &self.last_transactions
    }
    
    fn get_account_details(&self) -> AccountDetails {
        // Комплексные данные для UI
    }
}

// Синхронизация между моделями (через события)
struct AccountEventPublisher {
    // Отправка событий о изменениях
}

impl AccountEventPublisher {
    fn publish_deposit_event(&self, account_id: u64, amount: f64) {
        // Отправка в систему сообщений
    }
}
}

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write подсистем. Большинство бизнес-правил и сложных проверок находится во write — подсистеме.

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

CQRS хорошо подходит для моделей программирования на основе событий. Обычно CQRS разделяется на отдельные сервисы, взаимодействующие с Event Collaboration Это позволяет этим службам легко использовать преимущества Event Sourcing

Query - Для извлечения данных приложения следует использовать Query. «Запрос данных» всегда действует без сохранения состояния и не может каким-либо образом изменять состояние приложения.

Каждая обработка Command обрабатывается внутри одного UnitOfWork для обеспечить атомарность примененных изменений. Обработка нескольких Commands в последовательный способ (если требуется) может быть сделан с помощью Saga. Выданная Command может быть проверена и перехвачена/обработана другими Агрегирование через CommandValidators и CommandInterceptor.

Пример: CommandHandler обрабатывает команды (создание, обновление, удаление сущности) и возвращает соответствующие события. GetEntityQueryHandler обрабатывает запрос для получения данных о сущности. EntityRepository представляет репозиторий для хранения сущностей.

#![allow(dead_code)]
use std::rc::Rc;
use std::cell::RefCell;
use std::collections::HashMap;
// Команда для создания новой сущности
#[derive(Debug)]
struct CreateEntityCommand {
    id: u64,
    name: String,
}
// Команда для обновления сущности
#[derive(Debug)]
struct UpdateEntityCommand {
    id: u64,
    name: String,
}
// Команда для удаления сущности
#[derive(Debug)]
struct DeleteEntityCommand {
    id: u64,
}
// Событие, сигнализирующее об успешном создании сущности
#[derive(Debug)]
struct EntityCreatedEvent {
    id: u64,
    name: String,
}
// Событие, сигнализирующее об успешном обновлении сущности
#[derive(Debug)]
struct EntityUpdatedEvent {
    id: u64,
    name: String,
}
// Событие, сигнализирующее об успешном удалении сущности
#[derive(Debug)]
struct EntityDeletedEvent {
    id: u64,
}
// Запрос для получения данных о сущности
struct GetEntityQuery {
    id: u64,
}
// Результат запроса для данных о сущности
#[derive(Debug)]
struct GetEntityQueryResult {
    id: u64,
    name: String,
}
// Обработчик команд и событий
trait Handler<TCommand, TEvent> {
    fn handle(&mut self, command: TCommand) -> Vec<TEvent>;
}
// Обработчик запросов
trait QueryHandler<TQuery, TResult> {
    fn handle(&self, query: TQuery) -> TResult;
}
// Репозиторий для хранения сущностей
struct EntityRepository {
    entities: HashMap<u64, String>,
}
impl EntityRepository {
    fn new() -> Self {
        EntityRepository {
            entities: HashMap::new(),
        }
    }
    fn create(&mut self, id: u64, name: String) {
        self.entities.insert(id, name);
    }
    fn update(&mut self, id: u64, name: String) {
        if let Some(entity) = self.entities.get_mut(&id) {
            *entity = name;
        }
    }
    fn delete(&mut self, id: u64) {
        self.entities.remove(&id);
    }
    fn get(&self, id: u64) -> Option<&String> {
        self.entities.get(&id)
    }
}
// Обработчик команд для создания, обновления и удаления сущностей
struct CommandHandler  {
    entity_repository: Rc<RefCell<EntityRepository>>,
}
impl Handler<CreateEntityCommand, EntityCreatedEvent> for CommandHandler {
    fn handle(&mut self, command: CreateEntityCommand) -> Vec<EntityCreatedEvent> {
        self.entity_repository.borrow_mut().create(command.id, command.name.clone());

        vec![EntityCreatedEvent {
            id: command.id,
            name: command.name,
        }]
    }
}
impl Handler<UpdateEntityCommand, EntityUpdatedEvent> for CommandHandler {
    fn handle(&mut self, command: UpdateEntityCommand) -> Vec<EntityUpdatedEvent> {
        self.entity_repository.borrow_mut().update(command.id, command.name.clone());

        vec![EntityUpdatedEvent {
            id: command.id,
            name: command.name,
        }]
    }
}
impl Handler<DeleteEntityCommand, EntityDeletedEvent> for CommandHandler {
    fn handle(&mut self, command: DeleteEntityCommand) -> Vec<EntityDeletedEvent> {
        self.entity_repository.borrow_mut().delete(command.id);

        vec![EntityDeletedEvent { id: command.id }]
    }
}
// Обработчик запроса для получения данных о сущности
struct GetEntityQueryHandler {
    entity_repository: Rc<RefCell<EntityRepository>>//&'a EntityRepository,
}
impl QueryHandler<GetEntityQuery, Option<GetEntityQueryResult>> for GetEntityQueryHandler {
    fn handle(&self, query: GetEntityQuery) -> Option<GetEntityQueryResult> {
        if let Some(name) = self.entity_repository.borrow().get(query.id) {
            Some(GetEntityQueryResult {
                id: query.id,
                name: name.clone(),
            })
        } else {
            None
        }
    }
}
fn main() {
    let entity_repository: Rc<RefCell<EntityRepository>> = Rc::new(RefCell::new(EntityRepository::new()));
    let mut command_handler = CommandHandler {
        entity_repository: Rc::clone(&entity_repository),
    };
    let query_handler = GetEntityQueryHandler {
        entity_repository: Rc::clone(&entity_repository),
    };

    // Создание новой сущности
    let create_command = CreateEntityCommand {
        id: 1,
        name: "Entity1".to_string(),
    };
    let create_events = command_handler.handle(create_command);
    println!("Create Events: {:?}", create_events);

    // Обновление сущности
    let update_command = UpdateEntityCommand {
        id: 1,
        name: "UpdatedEntity1".to_string(),
    };
    let update_events = command_handler.handle(update_command);
    println!("Update Events: {:?}", update_events);

    // Удаление сущности
    let delete_command = DeleteEntityCommand { id: 1 };
    let delete_events = command_handler.handle(delete_command);
    println!("Delete Events: {:?}", delete_events);

    // Запрос данных о сущности
    let get_query = GetEntityQuery { id: 1 };
    let result = query_handler.handle(get_query);
    println!("Query Result: {:?}", result);
}

• CQRS
• DomainEvent martinfowler.com
• Patterns of Enterprise Application Architecture
• CQRS implementation
• CQRS implementation
• Command and Query Responsibility Segregation (CQRS)

Подход Domain-Driven Design (DDD)

TODO: добавить больше информации, пример, пояснение

DDD означает "Domain-Driven Design" (Проектирование с учетом предметной области) и представляет собой методологию и набор принципов, разработанных Эриком Эвансом. DDD ориентировано на решение сложных задач в области проектирования программного обеспечения, особенно там, где ключевой упор делается на моделирование предметной области.

Layered architecture

TODO: добавить больше информации, пример, пояснение

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

Hexagonal Architecture (Шестиугольная архитектура)

TODO: добавить больше информации, пример, пояснение

Hexagonal Architecture (Шестиугольная архитектура), также известная как Ports and Adapters (Порты и Адаптеры), это паттерн архитектуры, предложенный Алистером Кокберном. Он призван обеспечить легкость тестирования, гибкость и отделение бизнес-логики от деталей инфраструктуры.

Hexagonal Architecture поддерживает принципы чистой архитектуры (SOLID) и способствует созданию гибких, тестируемых и легко поддерживаемых приложений.

PoSA Архитектура программного обеспечения, ориентированная на шаблоны

PoSA

PoSA github.com/ppizarro

TODO: добавить больше информации, пример, пояснение

...