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

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

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

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

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

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

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

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

#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. Большое количество кодовой базы.