tgoop.com/reinforced_sc/84
Last Update:
Грануляция
Думаю, это одно из самых важных слов на сегодняшний день в IT. Оно очень ёмкое, потому что покрывает целый пласт проблем. Давайте на примере.
Все же читали про такой антипаттерн как god object? Ну это когда внутри одного-единственного класса прячется небольших размеров галактика. Он содержит кучу методов (дай боже если часть из них — приватные) и несёт на себе кучу разных обязанностей. Проще говоря — делает всё. От бана пользователей до подсчёта зарплаты сотрудникам. От записи в базу до маппинга web DTO-шек на модельные сущности. Таким образом, любая сколь-нибудь важная фича этот класс использует.
Очевидно, это плохо. Почему? Потому что при любых багах в любой части системы в этот класс будут вносится изменения. Как результат — непрерывные мерж-конфликты, порождающие мерж-баги, приводящие к ещё бОльшим конфликтам... Ну ладно, это решается (только в C#) модиификатором partial. А вот с тем, что при разработке любой новой функциональности скорее всего этот блоб тоже будет задействован и изменён — с этим уже ничего не сделаешь. Б-г будет внутри каждой фичи. Если две или более фичи собираются, то б-г будет между ними. На него надлежит молиться и уповать. Судьбы мирские будут вершиться им... В общем за полным списком всех оказываемых эффектов, добро пожаловать в Новый Завет. Даром что god.
А вот другая крайность: в PHP/CGI минимальная единица кода — это .php-файл. В концепции CGI, http-демон по сути запускал php как отдельный процесс, скармливал ему в STDIN web-запрос, получал от него в STDOUT ответ, после чего процесс php убивался. И это работало не только с php, а вообще с любым языком, на котором вы могли написать консольное приложение. Хоть с C++. В FastCGI процессы ещё и пулились. И это было чертовски удобно, плюс работало достаточно быстро. А ещё позволяло передеплоить любой обработчик любого POST/GET запроса не трогая всю остальную систему.
Кто помнит FastCGI, тот над serverless не смеётся. Если идти на поводу у мысли DevOps-ориентированных архитектов и линуксоидов со стажем, то можно заметить, что все их чаяния сводятся к тому, чтобы воспроизвести логику FastCGI, только с помощью других технологий. Ну и плюс ещё чтобы каждый из запросов можно было отдельно лоад-балансить, что, кстати, по-своему удобно. Представьте если у вас будет микросервис-на-запрос. Представьте каких и скольо у вас будет Dockerfile-ов, репозиториев и деплой-пайплайнов. И как они будут друг с другом связаны. Ужаснитесь.
О чём оба два вышеперечисленных случая? Они — о грануляции.
Грануляция — это политика дробления систем на подсистемы (классы на подклассы, функции на отдельные процедуры), дающая понимание с каким разбиением нам жить комфортно, построенная с учётом плюсов и минусов.
А теперь к плохим новостям: никакого готового рецепта "как нам правильно гранулировать?" не существует. Ответы в духе "так, чтобы не дублировать код", "микросервис-на-источник данных", "а нам и с монолитом ок" — незрелые ответы не мужей, но мальчиков. Правильный ответ только один: зависит от ситуации.
Хорошо когда в компании есть архитектор. Основная обязанность архитектора с моей точки зрения — следить за грануляцией в системе и вовремя выпихивать системы в подсистемы в нужных местах. И важно чтобы архитект был ОДИН. "Коллективная архитектура" — это миф. Пять человек не могут принять решение.
Ну и вот ещё что скажу. По моим наблюдениям одно плюс-минус универсальное правило грануляции всё-таки есть: группируйте по логике. Т.е. хороший микросервис — это микросервис, который целиком и полностью реализует какой-либо User Flow. SRP же, ну! Тут есть хорошая метафора: если у нас лёг микросервис для кредитования и пользователь, пришедшый в банк временно не может получить кредит — это приемлемо. Но если у нас лёг микросервис для входной двери и никто не может зайти в банк — это пипец.
Впрочем, про дверь я ещё напишу отдельно.
Такие дела
BY Novikov on Soapbox
Share with your friend now:
tgoop.com/reinforced_sc/84