Часть 1. Разочарование от нового проекта и фундамент для перемен
Часть 2. Выделенная команда и первый сервис по новому стандарту
Часть 3. Разбиение монолита по DDD
Часть 4. Создание шаблона микросервиса
➡️ Часть 5. Свой подход к интеграционным тестам
Часть 6. Что дало создание шаблона
Часть 7. Распиливание, миграции и оптимизации
Часть 8. Добровольный боттлнек, коммуникации и овертаймы за свой счет
Часть 9. Что нужно, чтобы драйвить такие перемены и оставить бизнес довольным
Часть 10. Почему распустили System Team и что в итоге?

Думаю стоит сказать пару слов о том, как мы решили задачу написания интеграционных тестов. Опять-таки, это идея из прошлого проекта. В чём его суть? На нашем проекте мы используем CQS подход. Оперируем commands и queries. На уровне имплементации для этого мы используем MediatR (.net-девелоперы меня поймут, но для остальных в двух словах это такая библиотека в .net, которая как раз и позволяет удобно работать с этими абстракциями на основе intelligent dispatching и т.д.). Работая с этой библиотекой в основном оперируешь следующими понятиями/объектами: commands/queries и command/query handlers. Так вот, по всем теориям, подходам, примерам в GitHub в Clean Architecture и commands/queries и command/query handlers есть не что иное как UseCases, и соответственно должны относиться к Application Layer.

И вот здесь мы вносим допущение на уровне всего проекта, скажем так, своего рода архитектурный допуск. Мы делим UseCases между Domain Layer (туда уходят commands/queries и для нас они становятся “абстракциями UseCases-ов”) и Application Layer (туда уходят command/query handlers и для нас они становятся “реализациями UseCases-ов”). Понимаю, что от сказанного можно получить волну хейта от “ортодоксов” Clean Architecture. Я понимаю, какие отрицательные сайдэффекты мы получаем от этого, но они не настолько значительны, и в корне не ломают Clean Architecture. А вот плюсы следующие.

От Domain Layer зависят все остальные слои приложения, но нас будут интересовать два - это Application и Infrastructure Layers. В Application расположены основные реализации UseCases (command/query handlers). А вот в Infrastructure у нас расположен прожект, выполняющий роль Client SDK этого сабдомена/микросервиса (паблишится этот SDK как nuget кстати).

И вот в этом проекте у нас вторые реализации UseCases (command/query handlers) только в основе которых уже не application logic, а просто HttpClient и запросы соответственно на API Layer этого же сабдомена/микросервиса. Т.е. По простому, что у нас получается? Получается Client SDK для микросервиса основанный на UseCases. Так а какие все-таки бенефиты?

Ну конечно для этого нужен своего рода тумблер на тестовом окружении, который будет переключать DI Container, в составе которого будет либо application реализация UseCase, либо Client SDK реализация.

И по итогу девелоперы одним махом закрывают два теста, хотя пишут только один. И в результате на этапе разработки фичи мы получаем более качественно проверенные артефакты еще до деплоя их на тестовое окружение. Девелоперы могут более быстро покрывать сразу два подуровня в Test Pyramid, не дожидаясь какого бы то ни было респонса от QA на тестовом окружении, пока оно там задеплоится, пока тестировщик проверит и т.д. Ну а QA остается только E2E тесты. Ну и corner cases;)

Ну и само собой это все мне пришлось тоже рассказывать и показывать, писать документацию. Был для этого организован отдельный Tech Talk на весь проект. Но как результат все всё поняли. Тесты пишутся.

Да, unit-тесты мы тоже писали, но только для Domain Layer (т.е. покрывали Entities, Value Objects, Domain services). Все остальное покрывается интеграцией плюс api. Тесты ради тестов не писали;). Все эти примеры, опять-таки, были в темплейте.

Шестая часть будет совсем небольшой – о документации, которой Павел с коллегами сопроводили шаблон, и том, что дало его внедрение.