Всем привет 👋

Собственно, хочется объяснить смысл того, что тут происходит...

Во-первых, я очень долго зрел для идеи завести свой канал о проектировании архитектуры ПО.

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

В-третьих, мне больше нравится идея канала, а не статей на хабре. Потому что тут я могу выдавать знания сериями и не вываливать на новичков тонны инфы.

Я надеюсь, что эта идея будет очень полезна всем присутствующим. Совсем скоро будет первый пост из цепочки постов про архитектуру ПО. Всем до встречи 🫡

#exp #gex #arch
Я столкнулся с Гексагональной архитектурой не так давно. Однако, этот паттерн проектирования архитектуры приложений настолько сильно захватил мои мысли, что теперь, работая над чужим ПО, я думаю "Какого 🤬🤬🤬 тут нет гексагоналки?!" 😅

❓Что такое Гексагональная архитектура?

#️⃣ Гексагональная архитектура - это паттерн проектирования, который был представлен Алистером Кокберном в 2005 году.

❓ Зачем нужен этот паттерн?

Гексагональная архитектура позволяет решить следующие проблемы:
1️⃣ Во-первых, проблему невозможности протестировать систему из-за модулей, зависящих от деталей других модулей;
2️⃣ Во-вторых, проблему перехода от одного технического решения к другому. Например, переход на другую СУБД, фреймворк и даже язык программирования;
3️⃣ В-третьих, проблему переиспользования модулей внутри одной или нескольких программ.

Сам же Алистер описывает задачу паттерна следующим образом:

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

Алистер Кокберн.

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

#arch #gex #exp
Что такое слои приложения, и зачем они нужны?

#️⃣ Слой - это некоторая область вашего приложения, которая инкапсулирует функционал части системы.

Идея разделить программу на слои - это не что-то новое. Программисты занимались этим задолго до гексагоналки. Однако, общепринятого "эталона" не было.

Тогда на свет пришла гексагоналка со своими стандартными слоями. А именно:

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

2️⃣ Слой приложения - в данном слое расположены ваши Use Cases. Это некие агрегаторы, которые вызывают несколько разных модулей.

3️⃣ Слой представления - здесь находятся ваши контроллеры, cli команды, страницы сайта и т.п.

4️⃣ Слой инфраструктуры содержит любые модули (адаптеры) для внешних систем (БД, Интеграции и т.п.).

Далее я расскажу о каждом слое более подробно.

#exp #arch #gex
Слой доменов

❓Из чего состоит слой доменов?
Как я писал ранее, слой состоит из бизнес сущностей и бизнес логики. Бизнес сущность - это ограниченный контекст вашего бизнеса, который подчиняется некоторому набору бизнес правил (бизнес логике).

Предположим, вы делаете сайт знакомств.

❓Какие можно выделить сущности?
1️⃣ Пользователь - информация о пользователе (ФИО, текст "о себе");
2️⃣ Лайк - запись о том, кто кого лайкнул;

❓Какие модули с бизнес логикой можно выделить?
1️⃣ Действие "Поставить лайк";
2️⃣ Действие "Отменить лайк".

А вот, например, действие "Загрузка фото пользователя" не будет являться доменной бизнес логикой - его следует выносить в слой приложения. И отслеживать эту операцию нужно через EventBus (о нем я обязательно напишу, когда буду рассказывать о слое приложения).

#exp #gex #arch
Кстати, на практике я заметил, что в доменном слое можно "обойтись" без реализации бизнес логики. И оставить в нем только интерфейсы, которые декларируют контракты модулей этого слоя.

Приведу пример:
Вы хотите сделать функцию "Поставить лайк" на вашем сайте знакомств. Вы делаете в доменном слое модуль, например, ApplyLike и пишите в нем свою логику. Вот тут и кроется подвох. В какой-то момент вы хотите использовать другую логику, но ваши Use Cases уже связаны с модулем ApplyLike. Решить эту проблему можно с помощью интерфейса ApplyLikeInterface. Такая реализация сделает ваш доменный слой более гибким и позволит легче масштабироваться.

❓Где же тогда разместить саму бизнес логику?

Все просто. Для интерфейса ApplyLikeInterface вы делаете слой DomainCore, для модуля ApplyLike с вашей бизнес логикой вы должны сделать Domain слой.

#exp #arch #gex
Порты и Адаптеры
Альтернативное название Гексагональной архитектуры - “Порты и адаптеры”. Это название лучше отражает принцип работы этого паттерна, так как шестиугольник (гексагон) не является строгим требованием паттерна, а вот наличие портов и адаптеров является одним из ключевых факторов.

❓Что такое порты?
Определение портов довольно простое. По сути это любая точка входа в вашем приложении. Это может быть графический интерфейс, командная строка, даже публичный метод класса - все это является портами.

❓Что такое адаптеры?
Точки входа (порты) мы определили. Теперь наша задача - передать данные через порты так, чтобы сохранился приемлемый уровень изоляции одного слоя от другого. В этом нам помогают адаптеры. Они позвляют транспортировать данные в другой слой, ничего не зная о деталях реализации модулей, которые мы хотим использовать. Максимум, который нам известен при использовании адаптеров, - это некий контракт взаимодействия.

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

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

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

#arch #note #solid
Направление зависимостей или Принцип инверсии зависимостей

#️⃣ Принцип инверсии зависимостей — The Dependency Inversion Principle или DIP — один из пяти основных принципов объектно‑ориентированного программирования и проектирования (SOLID), сформулированных Робертом Мартином.

Принцип декларирует, что:
1️⃣ Модули верхних уровней не должны зависеть от модулей нижних уровней, и оба типа модулей должны зависеть от абстракций;
2️⃣ Сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

#exp #arch #gex
Принцип инверсии зависимостей отчетливо прослеживается, когда мы используем слой представления, слой приложения, доменный слой и слой инфраструктуры. Стоит заметить, что при правильном использовании DIP все зависимости направлены внутрь системы. От конкретных деталей ко все более и более абстрактным модулям на других слоях.

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

#exp #gex #arch
Слой приложения

#️⃣ Давайте вспомним, за что отвечает слой приложения. В данном слое расположены ваши Use Cases. Это некие агрегаторы, которые вызывают несколько разных логических модулей.

Помните про действия “Поставить лайк” (ApplyLike) и “Отменить лайк” (CancelLike) из поста про слой доменов? В слое приложения мы можем сделать use case “toggleLike” - это будет переключатель лайка. Если пользователь кликает на фото другого пользователя и у него еще нет лайка, то лайк ставится (ApplyLike), в противном случае лайк отменяется (CancelLike). В данном примере toggleLike - это Use Case двух бизнес логик.

В гексагональной архитектуре действует постулат: все Use Cases должны храниться в слое приложения и только там. Также не забываем о том, что данный слой должен иметь порты и адаптеры для того, чтобы его можно было вызвать из других слоев, например, из слоя представления (API, GUI, etc.).

На самом деле, это практически все, что необходимо знать об этом слое - его не стоит сильно усложнять. Единственное, что мы позже в него добавим, - взаимодействие со слоем инфраструктуры через EventBus.