⚡Частые архитектурные паттерны
При разработке небольших сервисов можно часто встретить повторяющиеся архитектурные паттерны. Мой личный топ 3:
1. Отсутствие архитектуры
Никаких правил нет. Обычно нет разграничения на модули, что приводит к тому, что всё доступно из всего. Например, эндпоинты могут напрямую вызывать бд и работать с энтитями. Несмотря на всю диковатость, такая “архитектура” вполне может подходить для простейших сервисов/прототипирования
2. Слоеная
Идет логическое разбиение на слои. Какого-то общепринятого разбиения нет, но обычно это что-то в духе:
web -> application -> domain -> DB
где web - контроллеры, application - бизнес логика, domain - модель данных + репозитории, DB - база данных
Также часто применяются прямые зависимости, т.е. высокоуровневые слои зависят от низкоуровневых, что противоречит dependency inversion principle в SOLID. Такая архитектура вполне жизнеспособна для сервисов до среднего размера с не очень сложной бизнес-логикой. Но стоит оговориться, что в команде должно быть сразу установлено, как именно делим на слои, могут ли быть “сквозные” вызовы (web -> domain) и т.п.
3. Гексагональная
Концептуально другой вид архитектуры с точки зрения инверсии зависимостей. В центре находится основная бизнес логика, в которой описываются интерфейсы:
1) которые бизнес логика предоставляет во вне (in-порты)
2) интерфейсы, которые необходимы для реализации бизнес логики (out-порты), например, интерфейс доступа к данным
И далее “по бокам” располагаются компоненты, которые
1) используют интерфейсы предоставляемые бизнес логикой, например, web-контроллеры
2) реализации интерфейсов (адаптеры), нужных для бизнес логики, например, реализация интерфейсов доступа к данным через postgres
При этом важно отметить, что именно “побочные” компоненты зависят от бизнес логики, а не наоборот. Это позволяет реализовывать основную логику приложения без использования каких-либо зависимостей (framework Agnostic). Такая архитектура хорошо подходит для относительно больших проектов со сложной логикой, но и накладывает некоторый оверхед
А какой вид архитектуры вы обычно используете в своих проектах и почему?
При разработке небольших сервисов можно часто встретить повторяющиеся архитектурные паттерны. Мой личный топ 3:
1. Отсутствие архитектуры
Никаких правил нет. Обычно нет разграничения на модули, что приводит к тому, что всё доступно из всего. Например, эндпоинты могут напрямую вызывать бд и работать с энтитями. Несмотря на всю диковатость, такая “архитектура” вполне может подходить для простейших сервисов/прототипирования
2. Слоеная
Идет логическое разбиение на слои. Какого-то общепринятого разбиения нет, но обычно это что-то в духе:
web -> application -> domain -> DB
где web - контроллеры, application - бизнес логика, domain - модель данных + репозитории, DB - база данных
Также часто применяются прямые зависимости, т.е. высокоуровневые слои зависят от низкоуровневых, что противоречит dependency inversion principle в SOLID. Такая архитектура вполне жизнеспособна для сервисов до среднего размера с не очень сложной бизнес-логикой. Но стоит оговориться, что в команде должно быть сразу установлено, как именно делим на слои, могут ли быть “сквозные” вызовы (web -> domain) и т.п.
3. Гексагональная
Концептуально другой вид архитектуры с точки зрения инверсии зависимостей. В центре находится основная бизнес логика, в которой описываются интерфейсы:
1) которые бизнес логика предоставляет во вне (in-порты)
2) интерфейсы, которые необходимы для реализации бизнес логики (out-порты), например, интерфейс доступа к данным
И далее “по бокам” располагаются компоненты, которые
1) используют интерфейсы предоставляемые бизнес логикой, например, web-контроллеры
2) реализации интерфейсов (адаптеры), нужных для бизнес логики, например, реализация интерфейсов доступа к данным через postgres
При этом важно отметить, что именно “побочные” компоненты зависят от бизнес логики, а не наоборот. Это позволяет реализовывать основную логику приложения без использования каких-либо зависимостей (framework Agnostic). Такая архитектура хорошо подходит для относительно больших проектов со сложной логикой, но и накладывает некоторый оверхед
А какой вид архитектуры вы обычно используете в своих проектах и почему?