Поговорил с опытным архитектором, который больше 20 лет в 1С-сфере. Он зашел ко мне на ...
Поговорил с опытным архитектором, который больше 20 лет в 1С-сфере. Он зашел ко мне на VIP-тариф с «Автором курса». Интересная получилась беседа на тему нотации C4. Он делится болью: — Слушай, мы так бодренько на своих архитектурных комитетах разруливаем уровень C1, C2, а дальше мы не знаем, что делать? Как код то писать? И действительно. А дальше-то что? C1 в C4 — это уровень контекста системы: какую систему мы вообще делаем, кто ей пользуется, какие системы находятся вокруг нее и где проходят ее внешние границы. C2 — это уже контейнеры: на какие крупные исполняемые части делится наша система. Например: web-приложение, mobile app, backend, база данных и так далее. Если внимательно посмотреть на эти первые уровни C4, то по факту они говорят нам: Ребят, займитесь-ка инфраструктурой. Опишите-ка физическое разделение вашего приложения: здесь web, здесь mobile, здесь backend, здесь база данных, здесь еще что-нибудь. Если мы рисуем таким образом совершенно разные приложения — приложение для больницы, интернет-магазин, управление производством, — то плюс-минус получим одинаковые диаграммы. Где-нибудь будет авторизация, backend, mobile, база данных, еще пара внешних систем. Все. Квадратики плюс-минус одинаковые. Но ведь суть этих приложений вообще не в этом. Суть приложения для больницы не в том, что у него есть backend и база данных. Все самое интересное сидит внутри одного квадратика с надписью Backend. А как этот Backend написать? 👉 Как внутри него разделить ответственность? 👉 Где проходят логические границы? 👉 Какие там бизнес-правила? 👉 Какие инварианты? 👉 Что к чему относится? 👉 Кто за что отвечает? Это и есть настоящие проблемы. И рисованием квадратиков эти проблемы не решить. Причем сами авторы C4 говорят: C4 не задает вам процесс проектирования архитектуры. Это модель для визуализации и коммуникации. Она позволяет посмотреть на систему с разным увеличением, но не говорит вам, как эту систему правильно спроектировать. Если воспринимать C4 как процесс проектирования и начинать с C1 → C2, то смещается фокус внимания. Мы начинаем слишком рано думать о том, чем надо заниматься в самом конце. Конечно, бывают системы, где основная сложность именно техническая. Какой-нибудь проект с телеметрией, поисковый движок. Там вопросы latency, распределения нагрузки и прочего могут стать самым важным. Если мы говорим про бизнесовые приложения на 1С, то огромный кусок инфраструктурных проблем у нас уже решила фирма 1С. У нас есть платформа. И в ней уже очень много всего есть. Поэтому если мы начинаем архитектуру 1С-приложения с рассуждений уровня C1/C2 и слишком сильно на этом концентрируемся, то уведем фокус внимания от самого важного: От бизнес-логики. В итоге получим обычный распределенный ком грязи. Поэтому, ребятушки, C4, ArchiMate и остальные подобные штуки — прекрасные инструменты, чтобы что-нибудь пообсуждать. Для коммуникации — замечательно. Чтобы верхнеуровнево показать систему — хорошо. Чтобы посмотреть на нее с разных сторон — тоже хорошо. Но они не дают вам процесса проектирования архитектуры. Они не для этого. Сначала нужно понять предметную область и бизнес-правила. Найти логические границы. Разделить ответственность. Спроектировать приложение именно логически. А уже потом, когда все это появилось, открывайте C4 и рисуйте красивые квадратики: где это будет физически жить, какие приложения между собой общаются, какие контейнеры есть и так далее. Основная проблема — это логические границы. Над ними надо работать. А как потом хорошо разделенные логические части разложить по физическим границам, приложениям и серверам — это более простой вопрос. А вот если вы логически ничего не разделили и сразу занялись физическим делением — ничего хорошего из этого не получится. 👇👇👇