base_project_presentation

1.

Base Project
Architecture
Overview
An introduction to the project's structural design

2.

Обзор презентации base-project

3.

Ускорение запуска проектов
Base-project сокращает время старта новых сервисов, предоставляя готовую архитектурную основу и структуру.
Снижение дублирования
Единый шаблон устраняет ручное копирование настроек и кода между проектами, обеспечивая согласованность.
Упрощение командной работы
Base-project обеспечивает стабильность и предсказуемость, упрощая ревью, онбординг и сопровождение сервисов.

4.

Архитектурная основа
Единый проверенный шаблон
Base-project аккумулирует знакомые и проверенные практики
в одном удобном шаблоне для новых сервисов.
Основные архитектурные подходы
Включены Clean Architecture, DDD, Feature First, Modular
Architecture и Ports & Adapters для разделения
ответственности.
Поддержка долгоживущих сервисов
Фундамент обеспечивает предсказуемость, читаемость и
устойчивость к изменениям в больших сервисах.

5.

Domain слой
Фокус на предметной области
Domain слой организован вокруг бизнес-фич, а не
технических или инфраструктурных деталей,
обеспечивая структурированность кода.
Активные доменные модели
Модели отвечают за собственное состояние,
инварианты и операции, что предотвращает
анемичную модель и усиливает бизнес-логику.
Упрощение навигации и масштабирования
Разделение домена по фичам снижает
связанность и облегчает поддержку и
масштабирование системы.

6.

Infra-core
Назначение Infra-core
Infra-core хранит переиспользуемый
инфраструктурный baseline, объединяя общие
технические решения API-модулей.
Изоляция бизнес-логики
Infra-core не содержит feature-специфичную бизнеслогику, что обеспечивает чистоту архитектуры и
уменьшает связанность.
Упрощение сопровождения
Централизованные обновления компонентов
ускоряют поддержку и обеспечивают актуальность
технической базы новых сервисов.

7.

Управление схемой базы данных
Liquibase обеспечивает воспроизводимость и прозрачность структуры базы данных через код и миграции.
Структура миграций
Миграции организованы для удобства чтения и поддержки, включая основной слой и local bootstrap для
тестирования.
Улучшение developer experience
Liquibase формирует понятные правила работы с базой данных, ускоряя разработку и упрощая проверку сценариев.

8.

Глобальный
обработчик
исключений
Единый контракт ошибок
Global Exception Handler устанавливает
стандартизированный формат ошибок для API,
упрощая обработку ответов.
Централизованная обработка ошибок
Обработчик централизует validation и webошибки, исключая необходимость обработки в
отдельных фичах.
Разделение ответственности
Фича генерирует исключение, инфраструктура
отвечает за его корректное представление
клиентам.

9.

Infrastructure
слой APIмодуля
Отдельный инфраструктурный слой
Каждый API-модуль имеет свой infrastructure слой
для security, адаптеров и persistence-реализаций.
Разделение infra-core и модульной
инфраструктуры
Общий infra-core остаётся компактным и
переиспользуемым, отделён от деталей
конкретного сервиса.
Гибкость архитектуры
Изменения в одном API-модуле не влияют на
другие, обеспечивая гибкость и независимость
сервисов.

10.

Устройство infrastructure слоя модуля
Распределение ответственности
Infrastructure слой включает адаптеры, persistenceкомпоненты, репозитории, мапперы и специфические
месседжинг-компоненты для функций.
Определение инфраструктурного кода
Код, взаимодействующий с базами данных, Kafka, Keycloak
или HTTP-клиентами, относится к infrastructure слою модуля.
Роль infrastructure слоя
Infrastructure слой связывает бизнес-логику с технической
реализацией, сохраняя разделение бизнес-решений и
технических деталей.

11.

Outbox
Надёжная публикация событий
Outbox обеспечивает надежную отправку событий во внешние системы после
изменения данных в базе, исключая потерю информации.
Единая транзакция данных и записи
Данные и запись в outbox сохраняются в рамках одной транзакции для
согласованности и надежности.
Разделение бизнес-логики и интеграции
Отдельный обработчик публикует события, что развязывает бизнес-логику от
интеграционных деталей.
Гибкость использования Outbox
Outbox является примером для использования, а не обязательным
требованием для каждого сервиса.

12.

Адаптеры внешних систем
Подход Ports & Adapters
Application слой описывает порты, а infrastructure слой
реализует адаптеры для интеграции с внешними системами.
Роль адаптеров
Адаптеры обрабатывают вызовы внешних API, маппинг
контрактов и транспортные ошибки, исключая бизнес-логику.
Изоляция интеграций
Интеграции изолированы, что позволяет заменять или
удалять адаптеры без изменения бизнес-сценариев.

13.

Application слой
Роль Application слоя
Application слой выступает как orchestration
layer, управляющий последовательностью
операций и сценариями использования.
Функции Application слоя
Он проверяет входные параметры и
управляет транзакциями без включения
бизнес-логики или инфраструктурных
деталей.
Разделение Domain и Application
Чёткое разделение между domain и
application повышает читаемость кода и
облегчает тестирование сценариев.

14.

Тестовый подход
Тестирование доменного слоя
Unit-тесты на domain уровне проверяют бизнесинварианты и поведение моделей без
инфраструктуры.
Тестирование application слоя
Тесты application слоя проверяют порядок
вызовов и взаимодействие с port, обеспечивая
корректность сценариев.
Быстрая обратная связь
Подход обеспечивает быструю обратную связь и
защиту архитектурных границ системы.

15.

Конвенции по тестам
Структура тестов по слоям
Тесты структурированы согласно архитектурным слоям и
модулям, обеспечивая ясность проекта и тестов.
Распределение тестов по логике
Domain тесты находятся рядом с доменной логикой, use case
тесты проверяют оркестрацию, mapper тестируется как
boundary logic.
Развитие конвенций
Конвенции по тестам гибкие и эволюционируют вместе с
шаблоном и потребностями команды.

16.

Старт нового
модуля
Практическая стартовая точка
Base-project служит основой для новых сервисов,
облегчая начало разработки и интеграцию новых
функций.
Стартовая документация
В шаблоне есть документация, которая
объясняет, что оставить, а что удалить, упрощая
процесс адаптации.
Актуальность документации
Все изменения baseline должны отражаться в
документации, чтобы команда имела всегда
актуальную информацию.

17.

Roadmap
Краткосрочные планы
Включают логирование, трассировку, Redis и
упрощённую версию шаблона без примерной
бизнес-логики для быстрого запуска.
Долгосрочные инициативы
Включают GraalVM, circuit breaker и
выделение конфигураций в отдельную
библиотеку для централизованного
управления.
Живой платформенный продукт
Roadmap направлен на создание платформы,
которая развивается вместе с командой и её
архитектурными потребностями.