Я в Project Mariotte сделал страшное - перешёл на MockMvc.
Изначальная мотивация была в том, чтобы сэкономить секунду на запуске Tomcat.
Потом выяснилось, что инициализация RestAssured занимает ещё секунду, которую тоже можно сэкономить
Но последним аргументом стало то, что со WebTestClient можно переехать на работу через HTTP за
И это навело меня на мысли об эволюции ЭП от сложного к простому за последние 4 года.
В конце 19-ого - начале 20-ого года можно было сказать, что ЭП = модульный монолит + тесты без моков + ДДД + чистая архитектура + railway-oriented programming на монадах.
И на тот момент, это всё (на мой взгляд) были маргинальные идеи, не имеющие широкого распространения.
Но за прошедшие 4 года, они все если не вошли, то сильно приблизились к мейнстриму, на мой взгляд.
А я с ЭП за эти же 4 года то ли ушёл вперёд, то ли откатился назад:
1. К модульному монолиту добавились цитадели, а для самого монолита появилось ограничение, что типовой тест должен отрабатывать не больше чем за 30 секунд
2. В тестировании добавилось разрешение на использование моков для симуляции ошибок инфраструктуры и для дорогой инфраструктуры. И свеженькое разрешение на использование MockMvc, при условии, что код самих клиентв (тест-кейсов) на него не завязан.
3. От ДДД осталась только декомпозиция модели на агрегаты, но по более приземлённой технологии на базе жизненного цикла сущностей и транзакционного анализа; а вместо ограниченных контекстов - декомпозиция на базе эффектов;
4. Чистую архитектуру я заменил на тщательное проектирование интерфейсов;
5. ROP на монадах, наконец, я заменил на Guard clause.
И при этом Эргономичный подход остаётся совместимым со всеми этими идеями там, где это надо:
1. Цитадель оказалась плохой затеей? Затолкать её обратно в монолит - вообще не проблема;
2. Тестов на моках стало слишком много или появилось слишком много багов в обработке ошибок? Поменять моки на стабы - уже сложнее, но тоже вполне решаемая задача;
3. В проекте появилась сложная предметная область и/или эксперт по ней? Перейти на ограниченные контексты и агрегаты на базе инвариантов - без проблем, вся инфраструктура и структура кодовой базы готовы;
4. В проекте появилась необходимость менять инфраструктуру без пересборки/перезапуска? Вытащить интерфейс из существующего класса - дело 5 минут. С реализацией сложнее, но это другой вопрос;
5. В проекте появилась потребность на лету собирать пайплайны? Обернуть имеющиеся вызовы эффективных методов в монады не составит труда.
А прямо сейчас, в моменте, ваш код будет максимально простым, без лишних сложностей и архитектуры.
Изначально Эргономичный подход был глотком свежего воздуха для тех, кто устал от хаоса и багов императивной слоёнки с тестами на моках.
Теперь Эргономичный подход стал глотком свежего воздуха для тех, кто устал от поисков стороны, с которой подойти к ДДД, церемоний чистой архитектуры и сложностей объяснения монад простым смертным.
В общем, покой нам только снится:)
#ergo_approach@ergonomic_code #project_mariotte@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #mocks@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture@ergonomic_code #ddd@ergonomic_code #rop@ergonomic_code
