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

Так получилось, что внезапно появляется еще одна команда. И надо там заткнуть позицию BE-девелопера. Я туда ухожу на какое-то время. Этот период предлагаю опустить, ничего значимого тогда не произошло. Немного позже начинаются разговоры про то, что на этом проекте неплохо бы заиметь инфраструктурную тиму. Мы ее называли System Team.

Это, на самом деле, супер уникальный кейс. Я предполагаю, что очень мало где такое есть. Возможно, только на больших каких-то интерпрайзах. Например, ни у кого из моих знакомых, которые работают в разных странах, на разных проектах, ничего подобного нету. Но мы решаем попробовать. Эта команда должна была находиться как бы “над фича-тимами” и отвечать за всю инфраструктуру проекта.

В общем, появляется идея о такой команде. Почему она начинает появляться? Примерно в то время на проект приходит TeamMember S с моего предыдущего проекта, на позицию DevOps/Architect (больше все-таки DevOps). Я с ним тоже пообщался.

Говорю:

Потом мы поговорили втроём: я, TeamMember S и TeamMember V. Посмотрели на проблемы, которые были на тот момент, и решили доводить эту информацию до более высокого менеджмента. Ну и пошло-поехало.

Мне одному не хватило бы сил эту команду создать. То есть вот, опять-таки, еще одно стечение обстоятельств: еще один человек появился, который помог сдвинуть все с “мертвой точки”. И так получилось, что именно в тот момент вся команда проекта начала расти, и заказчик был в целом не против такого рода экспериментов. В общем много совпадений случилось.

Решение принято – команда создается. Кто был в этой команде? В этой команде было три BE-девелопера, включая меня. Потом добавился еще один. Был один AQA. FE-девелоперов не было, потому что не было необходимости. Я был TeamLead-ом этой команды. Полностью, что мы делали, я не буду рассказывать, потому что мы так не успеем поговорить про более интересные вещи.

Но начали мы с того, что мы релизнули сервис аутентификации на этом проекте по всем канонам, которые я пытался продвигать ранее. То есть мы перевернули всю аутентификацию и авторизацию на проекте.

Да, кстати, пока мои ребята в команде пилили вот этот сервис аутентификации, я начинал знакомство, более глубокое знакомство со всем бизнесом. Здесь было что-то вроде SOA. То есть были такие большие backend-овые сервиса. Некоторые из них, самые большие, выполняли роль BFF.

Для чего мне это было нужно? Мне это было нужно, чтобы понять, как вообще этот бизнес/проект работает целиком, чтобы распилить его на микросервисы. Для декомпозиции проекта на микросервисы был выбран паттерн Decompose By Subdomain. Их два – Decompose By Business Capability и Decompose By Subdomain. На предыдущем проекте Decompose By Subdomain показал себя вполне неплохо. Да, здесь можно сказать, что я с прошлого проекта тянул какие-то знания в полной мере не разобравшись и т.д., но, в принципе, он сюда лег очень неплохо.

Был отдельный Epic по переводу всего проекта, всех остальных сервисов, которые там были, на использование сервиса аутентификации. Постепенно переводили. Была инкорпорация с участием других команд. Мне приходилось активно использовать коммуникейшн скилл. Было очень много общения с тимлидами других команд, с BE-девелоперами, которые будут применять это API, с FE-девелоперами, у которых вообще там все переворачивается, весь authentication flow.

Писалась отдельная документация на Wiki. Плюс Swagger был must have, он использовался. На прошлом проекте я такого не делал, но здесь это очень помогло для инкорпорации - мы активно применяли request и response examples для Swagger-а. Учитывая то, что мы активно использовали Discriminated Unions при разработке Domain model.

Что такое Discriminated Unions (DU) в .Net? В двух словах – это enum “на стероидах”. То есть это когда у enum, помимо какого-то целочисленного и строкового значения есть еще какой-то state. В принципе, думаю, сможете загуглить позже, чтобы не тратить много времени.

Так как в request payload присутствовали DUs, в response внутри моделей присутствовали DUs, а Swagger by default их не может нормально прочитать, то приходилось много времени тратить на request и response examples для Swagger-а для того, чтобы показать клиентам Swagger-а, какие могут быть варианты этих DUs в контрактах и респонсах.

Кстати немного позже был и TechTalk, где один из топиков был Effective auto-generated documentation, где я как раз и показывал подход request и response examples для Swagger-а. На том TechTalk наши AQAs на проекте (у нас была automation team отдельная) были в восторге. Говорят: “круто, давайте вообще это везде применять”. И всё, после этого это стало стандартом тоже.

В общем, да, инкорпорировали у себя новый сервис аутентификации все. То есть, все те команды, у которых была FE часть в responsibility area. Делали это команды в параллель.

В следующей части начинается самое интересное – разбиение монолита по DDD. Оставайтесь с нами!