#note #cbse #arch
Компонентная разработка программного обеспечения | Component-based software engineering (CBSE)

❓ Что такое компонентная разработка?

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

❓ Когда следует использовать?

1️⃣Когда компоненты должны быть заменяемыми. Это означает, что компонент должен быть заменен другим, имеющим те же интерфейсы, без нарушения остальной части системы.
2️⃣Когда компоненты должны быть многоразовыми.

#exp #arch #gex
Разделение на компоненты и слайсы (Feature slicing)

Компонентно-ориентированную разработку можно использовать где угодно. Эта парадигма не связана с гексагональной архитектурой напрямую. Однако, паттерн гексагона описывает некий Component (закрашенная синяя область на схеме), в котором стоит разобраться.

❓ Что такое компонент с точки зрения гексагональной архитектуры?

В гексагональной архитектуре под компонентом понимается набор модулей, который относится к одной конкретной сущности вашего приложения. Это может быть бизнес-сущность Пользователь, Товар или что-то еще. Самое главное, что модули этого компонента могут находиться на разных слоях и объединяться в CBSE компоненты.

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

1️⃣ Термин компонент подразумевается только в конексте CBSE;
2️⃣ Набор компонентов, которые можно сгруппировать на нескольких слоях, будет называться слайс (slice или feature slice);
3️⃣ Составление компонентов происходит по правилам CBSE. За одним исключением: компоненты на внутреннем уровне не должны зависеть от компонентов на внешнем уровне. Соблюдаем принцип инверсии зависимостей.

❓ Чем полезен feature slice?

Слайсы привносят в паттерн гексагональной архитектуры не только понятие CBSE, но и способ организации кода. Когда вы думаете не только о том, как организовать компонент, но и о том, как организовать слайс, то проект становится более структурированным. Это позволяет не только быстро и удобно разрабатывать фичи, но и делать это максимально изолированно от других слайсов и их компонентов.

#arch #cqs #cqrs #note
Command Query Responsibility Segregation (CQRS)

❓ Что такое CQS (Разделение команд и запросов / Command-Query separation)

Первым упоминанием CQS считается книга B. Meyer Object Oriented Software Construction. Основная идея CQS заключается в том, что в объекте методы могут быть двух типов:

1️⃣ Команды (Commands) - методы, которые изменяют состояние объекта, не возвращая значение;

2️⃣ Запросы (Queries) - методы, которые возвращают результат, не изменяя состояние объекта.


❓ Что такое CQRS (Разделение ответственности на Команды и Запросы / Command Query Responsibility Segregation)

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

Преимущества CQRS включают:

1️⃣ Независимое масштабирование. CQRS позволяет раздельно масштабировать рабочие нагрузки чтения и записи, снижая риск конфликтов блокировки.

2️⃣ Оптимизация схем данных. Для процессов чтения можно применить схему, оптимизированную для запросов, а для процессов записи — другую схему, оптимизированную для обновлений.

3️⃣ Четкое разделение зон ответственности. Разделение процессов чтения и записи позволяет получить более гибкие и простые в обслуживании модули. Бо́льшая часть сложной бизнес-логики переместится в модель записи. Это в некоторой степени упростит модель чтения.

4️⃣ Более простые запросы. Сохраняя в базе данных для чтения материализованное представление данных, вы предотвратите использование приложением сложных соединений в запросах.

https://cqrs.nu

#exp #gex #arch
Command/Query bus на практике

Когда мы принимаем на вход какие-либо данные от пользователей, мы обязательно валидируем входящие данные и формируем ответ в нужном формате. Обычная схема в таком случае это Controller => Use Case => Domain Logic => Responder.

Controller - принимает и валидирует данные;
Use Case - агрегирует и использует доменную логику (Domain Logic);
Responder - формирует ответ в нужном формате.

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

Решением подобных проблем являются внедрение правил CQRS и организация слоя Command/Query bus.

❓ Что такое Command/Query bus?

CQB - это изолированный слой системы, который несет ответственность за все входящие данные и формирует выходящие данные.

Для CQB можно выделить следующие задачи:

1️⃣ формирует команду/запрос;

2️⃣ валидирует команду/запрос;

3️⃣ передает её в обработчик команды/запроса;

4️⃣ обработчик команды/запроса формирует ответ*.

* В случае команд (запись данных) можно отдать стандартный ответ из контролера

CQB унифицирует работу с входными/выходными данными и предотвращает передачу некорректных данных в слой бизнес логики.

#exp #arch #gex
Выводы о Гексагональной архитектуре

✅ Преимущества

1. Строго декларируются зоны ответственности, которые инкапсулируются в слоях приложения;
2. Бизнес-логика отделяется от логики системы, что упрощает миграцию кода;
3. Строго определяется направление зависимостей в соответствии с DIP;
4. Исчезает проблема зависимости от конкретных технических и технологических решений;
5. Бизнес-логика и системная логика отделяются от модулей представления;
6. Появляются правила объединения модулей в компоненты, которые можно переиспользовать в других системах;
7. Появляются правила CQRS, позволяющие увеличить производительность системы.


🚫 Недостатки

1. Очень высокий порог входа в концепции паттерна;
2. Увеличение количества слоев может затруднить понимание работы системы;
3. Большое количество кодовой базы.