Приложение разделено по ограниченым контекстам на микросервисы. В ветке part_1 можно увидеть как на начальном этапе приложение было модульным монолитом.

Каждый микросервис реалзиован по принципу чистой архитектуры (Clean Architecture), бизнес-логика реализована паттернами Domain-Driven Design'а (Aggregates, Entities, Value Object, Domain Services). За структурой проекта следит ArchUnit.

На данный момент СУБД используется только для одного агрегата, все остальное есть InMemory-реализация хранилищ.

Также мы постарались реализовать принцип кричащей архитектуры (Screaming Architecture). Структура проекта отражает назначение проекта и функциональность, тоже самое касается пакетов и даже отдельных файлов

Решения о важных архитектурных решениях содержатся в Architecture Decision Records

Основная идея - разработчику должно быть максимально удобно работать за локальным компьютером. Поэтому все необходимые действия с проектом можно совершить нажатием одной "кнопки", которые находятся в tools/scripts. Таким образом в полной мере реализуем концепцию CI. В качестве предохранителя используется GitHubActions. В случае падения сборки в артефакте reports есть вся необходимая информация для диагностики. Для пуша можно установить pre-push hook, который будет прогонять всю сборку целиком перед заливкой в репозиторий.

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

• Статанализатор detekt
• Линтер - ktlint, (как плагин к detekt)
• Контроль тестового покрытия JaCoCo
• Поиск уязвимых зависимотей OWASP DependencyCheck
• Поиск новых версий для зависимостей
• Контроль отсутствия предупреждений компилятора

Зависимости перечислены в ProjectDependencies.kt

"Кнопками" из tools/scripts можно разворачивать и останавливать кластер на рабочей машине разработчка без необходимости занимать стенды.

Пирамида тестов, реализованая в проекте

• Юнит-тесты
• Интеграционные тесты
  • Тестирование репозиториев
  • Тестирование клиентов к внешним сервисам
• Контрактные тесты Pact.io
• Компонентные тесты
• Сквозные тесты kbdd + Allure
• Тесты структуры проекта ArchUnit
• Мутационные тесты PiTest
• Нагрузочные тесты Gatling

В примере реализованы примеры

• Асинхронного взаимодействия между микросервисами через RabbitMQ
• REST уровеня HATEOAS - Spring HATEOAS
• Использования паттернов устойчивости (на примере библиотеки)
• Централизованой обработки ошибок
• Валидации ввода моделью предметной области
• Взаимодействия через Telnet (библиотека ktelnet, скопирована в репозиторий с исправлением нескольких ошибок)

Miro board

In Progress

In Progress

In Progress

Ставьте звезды и приходите к нам в Телеграм-канал