C4 для системного аналитика: строим единый язык между бизнесом и разработкой

Привет. А завершить? Нет звука. Давайте проверим. Звук есть. Шикардос, что звук есть. Спасибо, Сергей. Так, как этим всем удобнее будет управлять? Я не знаю. Ну, погнали. Давайте знакомиться.

И так, я себя не вижу, потому что экран слишком маленький. Надеюсь, что вам меня видно хорошо. Где-то там справа, да? Отображение видеоокна участника. Убрать с экрана. Мы видим вас. Антон, спасибо, Стас. Ну и О, вот так я себя вижу. И ещё маленький экранчик. А вот так вот движется. Вообще шикарно. А сейчас всё изменим. О, так лучше. Но если у вас был 2,5к телефон экран, то стало хуже.

Так, нас 32 человека. Это просто невероятно. Вы представляете, мы мне сегодня с утра написали, что даже если я не готов, я всё равно должен вам что-то рассказать. Так вот, с этого момента надо вырезать. И давайте начинать.

А мы с вами пришли, чтобы узнать, как примерно происходит взаимодействие на вебинарах в рамках курса "Системный аналитик, управления командой". Выбрал я тему достаточно простую, как мне кажется, C4 для системного аналитика. И почему эта простая такая модель нам поможет построить некий единый язык между бизнесом и разработкой? Возможно, цель слишком большая, поэтому вас здесь так много, а, возможно, она решается очень просто.

Итак, давайте познакомимся. Я поставлю звёздочки для себя. Они не попадут ни на какую запись в чате, что очень странно. Напишите вообще C4. Для вас что-то новое сегодня будет или вы это уже внедряете? А пока вы вспоминаете, я расскажу про себя. Меня зовут Геросименко Антон. Почему-то я на видео не отображаюсь. Ну ладно. О, вот теперь, да. Занимаюсь тем, что разрабатываю по для не так. Мы разрабатываем экосистему продуктов, связанных с видеонаблюдением. Там много очень интересных моментов. И я лидирую командой разработки, которые двигают порядка десяти разных сервисов. код на дотнете и в основном пишу и ещё лидирую команду фронтенда, поэтому знаю какой-то тайpesрипт. Воттусе я рассказываю на дотнте курсах по базам данных, по системно по системному дизайну, но не для того, чтобы проходить интервью, а для того, чтобы познакомиться с тем, как строить и описывать системы. То есть там мы глубоко копаем каждую из тем. Вот. Ну, в целом, если вы уже проходили как-то этапы интервью по систем-дизайну, а некоторые компании хотят тоже глубоко покопать какую-нибудь часть из из того, что мы строим, например, про кэш поговорить или как работает loadбалансер, как работает консенсус, рафт и так далее. И системный аналитик, тот курс, на котором я рассказываю такие архитектурные темы. Про нефункциональные требования меня пригласили один раз рассказать. Я и ещё что-то про программирование тоже там есть.

Так, я ж могу вам поделиться вот этой ссылкой. Чат, это всё, где можно меня встретить. Плюс ссылки на другие открытые уроки. Про вебинары в самом отпусе. Здесь самое важное - это то, что есть вот это онлайн общение между нами и вами. Это не просто какие-то видосики. И основная задача - это именно поделиться какой-то информацией здесь онлайн.

Так, немножко узнали. Новое для вас, не новое, а отписалось не так много людей. А, но давайте ещё и дополнительно напишем, что вы сегодня хотите услышать из интересного, увидеть. Какая ваша должность? Из какого вы города, на чём к нам сегодня добрались? Я вот на велосипеде приехал. Пока вы пишите, чтобы было не скучно, что у нас в фотусе есть. 130 курсов, даже, наверное, уже больше разных направлений. Есть лицензия на введение преподавательской деятельности, образовательной деятельности, поэтому выдаётся диплом о повышении квалификации. Классная штука. Возможно, скоро будет нужна чуть сильнее, чем 2 года назад. Охвачено весь мир IT, но и плюс дополнительно не только IT. Вот, например, недавно запустили курс и для юриста. Поэтому если вдруг у вас есть юрист, который не понимает, как жить сегодня, можете ему посоветовать. послушать какие-нибудь темы, связанные с ним у нас на курсе.

Так вот, Виталий говорит, что он из Перми. Привет. Круто. Я был месяц назад в Перми. Познакомиться, что такое C4, какие задачи решает. А Марат из Питера, как другие используют С4. Стас руководит командой технической документации, используемых документаций С4 в общении с аналитиками и архитекторами. Круто. Стас тоже можете что-то рассказывать. А в целом прос я вам рассказал. Познакомиться с S4 камеля как хочет из Москвы. Самара, начальник отдела развития IT на заводе нужно прокачать теорию IT-менеджмента. Круто, Николай. Вот эти технические директора всегда вызывают у меня трепет.

Так, ссылочку на презентацию я потом ещё раз потошлю. Если вдруг вы смотрите с телефона, можете сразу сфотографировать. Вот это всё, что мы видим здесь, оно опубликовано в интернете. Можно смотреть и на эти картинки. Какой маршрут, чтобы вдруг мы с вами не потерялись, я хочу поговорить с вами про архитектуру как код. Это, с одной стороны что-то новое, с другой стороны хайповое в течение последних нескольких лет. А, и просто обсудим, к чему это нас приведёт. Потом посмотрим на диаграммке C4. Я не обещаю ничего, как это используется в других компаниях. Будет такое достаточно ознакомительное занятие. У нас не так много времени. А, и я сразу пришёл сюда с мыслью, что мы просто проведём какое-то базовое по ним задачу про знакомство с C4. А, поговорим про плюсы, минусы, то есть какие задачи закрывает, какие точно не закроет. И про курс примерно так же, как про вот послушали то же самое.

Так, Лиля, только теория не приходилось пока проектировать. Хочу красти как архитектор. Круто. Итак, цели. Разобрать подход и выбрать инструмент. Ну, давайте ещё чуть-чуть поработаем пальцами, а потом будем только ушами. Вот у нас есть необходимость как-то описать архитектуру. Какой инструмент вы для этого возьмёте? Ну или там архитекте решений. Вот кубики и стрелочки. Отлично. Архимей Арчи SPK. Ого, ничего себе, круто. Так, с этим разобрались. Теперь вопрос с теми же самыми ответами. Ээ прямо в планте, а это, видимо, план email. Какие вообще нотации вы можете сейчас вспомнить и какие из них использовали или сейчас используете? Я вот вспомнил не так много, поэтому воспользовался поиском. Я вам предлагаю именно повспоминать. А, и когда несколько аббревиатур отобразилось в поиске, я прямо вспомнил это прекрасная университетская, а, а, spar X, а, тогда я не знаю. Так вот, L BPMN. А тут прикольно, да, что в БПМН есть буковка Н, которая означает как раз-таки вот эту фразу, что нотации. Мне было интересно просто в английском языке знают слово нотации или используют везде unific language? SPARX System Enterprise Architct. Прикольно, что вспомнили не так много, наверное, потому что редко, когда мы применяем вот это некое академичное название аббревиатурам, подходом, который звучит как нотация, и их получилось вот примерно столько. Архимей все вспомнили, очень круто. А, и на самом деле, в принципе, если вы используете Архимейд, вам он понятен и не занимает много времени, то C4 вам только для того, чтобы понимать, что есть что-то такое похожее для рисования квадратиков и стрелочек. Э, вот, да, про IDF я как раз-таки и вспомнил. BPMN, UML, это всё что-то, что должно было заставить людей писать код. Вот эти все нотации мы сейчас картинками нарисуем и потом при помощи какого-нибудь транслятора переведём это в код и разработчики будут снова не нужны. ID вот эти схемы S is to be, которые рисовались в универе, я их вспомнил, я уже не помню, что это такое. Разновся флоучарты и чуть-чуть поинтереснее. Анотации. Это 4 +1 архитектура в её модель, в которой рассматривается любое строение системы как включающий логический вид. Процессный вид. О, так ставим лишнее что-то. вид по разработке физический и всё это объединяет какие-то сценарии. CSML можно посмотреть на него. Я вообще первый раз наткнулся на эту аббревиатуру, и что-то в ней прикольное, в принципе, есть. То есть он, ну, когда загрузится, позволют всё запустить. Э- и АL более такая зарегулированная история история по разработке описания архитектур. Из описания следует, что в основном как используется где-нибудь там в военке, в авиастроении, но в целом можно посмотреть на то, как это всё строится. И там больше именно идёт история про то, что мы строим нечто отказоустойчивое. И вот туда вписалась C4 модель. Зачем нам вообще что-то описывать? Ну, когда мы либо рисуем на салфетке, и в зависимости от того, какая у нас культура в компании по построению процессов описания проектируемой системы, а, мы можем получить разные личные артефакты. В Прикольно, что ещё кто-то IDF0 использует, да? Это пример неплохой построенной системы при помощи стрелочек и квадратиков. Но что здесь происходит, в принципе, понятно только в момент рисования, скорее всего, и в момент объяснения, что здесь происходит. Со временем будет вообще тяжело понять. И это ещё неплохой вариант. Я вот, кстати, когда готовился, хотел показать примеры ребят, которые на систем дизайне в начале рисуют. Ну и примерно то же самое будет, например, когда вы не готовились к интервью, пришли, вас ошарашили, давайте пройдём systemдизаign сессию, и вы такие: "Да что там, я настолько системный аналитик, что мне это ничего не стоит пройти". Всё получается, конечно, не очень красиво, поэтому в любом случае нужна какая-то тренировка. Но мы сегодня не про эту сессию, мы про то, как описывать. Ну вот мы получили такой артефакт. Тут сразу low level дизайн, high level дизайн в этом по этой ссылочке будет примерно такой же. Ну вот у нас есть набор кубиков, они как-то между собой взаимодействуют. И возникает сразу вопрос, нет ли возможности как-то более структурированно к этому подходить и использовать модные нынче явления как код. Да, у нас инфраструктура как код, у нас сервис как код. В общем, всё как код. У А Озона даже их конференция ежегодная называется Evering CASCД. И архитектура тоже решила сюда прийти. А, да, документация как код. Это очень круто, на самом деле, потому что когда слышишь истории, что где-то документация хранится в ворде, то становится немножко страшно. Ведь есть же нормальные форматы современные, там текстовые, в котором ничего не нужно. Есть сервисы, которые по этим текстовым документам хорошо партсят htмлкуlку и так далее. Или из кода делается автогенерация кода, автогенерация документации. Зачем нам это всё нужно? Мы получаем некое описание архитектурной модели в виде читаемого, а самое главное, версионируемого кода. И у нас создаётся некий артефакт, который становится единым источником правды. Что делать дальше с архитектурой? Какко? Ну, естественным развитием для этого у нас получается история преобразования всех тех единиц, из которых мы построили. Теперь уже машина читаемого или машина генерируемого, что тоже неплохо, да? То есть мы можем отдаватьишке задачу, она в какой-то нотации нам её предложит, и в зависимости от умения работать в этой нотации мы получим каком-то виде исходники для дальнейших артефактов. Это очень важно. А потому что просто так код он будет вакууме, да? Ну, какие-то буковки. Хорошо. А первое же, что мы можем по ним сделать - это то, что ради чего какую проблему и решали. Это некрасивые диаграммы. К сожалению, задача решить некрасивые диаграммы не решается, потому что автолей-ауты очень часто сбоят, и поэтому нам нужны инструменты, которые генерируют этот лейаут при построении диаграммы, потом позволяют перемещать квадратики и сохранять место расположение каждого квадратика, куда мы его переместили. чтобы потом при повторной регенерации нам не пришлось делать опять этот машинный труд, связанный с перемещением. А и какую цель мы вообще преследуем? Это получить какую-то согласованную архитектурную модель. А мы больше не думаем о том, как расположить красивые квадратики. Они у нас создаются сами собой. Мы описываем внутрянку, некое содержание и уже сосредотачиваемся для того, чтобы работать на проверке полноты, корректности данных. Включаем всё в проверке. Следующий шаг, естественный, связанный с архитектурой, как код, это будет тесты на код, связанные с архитектурой. И тут уже поле для много интереснее, да, получается. У нас есть возможность проверить, что мы что-то не забыли. Например, потерялась какая-то стрелка. В в тестах описали, кто с чем должен взаимодействовать, как на какой выход получить. Хоп, проверили, не получилось. Это уже, наверное, очень высокий уровень культуры описания этих архитектурных решений. Сразу скажу, я об этом ничего не знаю с точки зрения практики. Есть вот из ПК Техлит Конфа Saфин. Он очень часто про это рассказывает в последнее время. Ну и вообще про тестирование архитектуры как код. Тема популярная, наверное, стала в последние два, максимум 3 года. Можно туда посмотреть, но это уже так или иначе будет связано с написанием каких-то скриптов. Плюс дополнительно вот эти написанные скрипты нам позволят увеличить количество выполняемых проверок и валидаций. Например, мы можем проверить, что все протоколы указаны врах правильно. Включим это на этапе сия. И вот у нас не будет какая-то новая архитектура перестроена документация, которая у нас автоматически строится по нашим предварительным маркдауном и адрам, как в семьдесят первом году, как говорит Стас. А, и это, наверное, неплохо, потому что мы больше сосредотачиваемся на смыслах, чем на форме. И нам открывается прекрасное окно возможностей. начать моделировать угрозы, связанные с нашей архитектурой. Мы можем выгрузить доверенные границы, потоки данных, механизмы защиты, проверить, что на каждом слое у нас указано, что необходимо как-то ограничивать контексты. Например, у нас должны базы данных не быть в открытом контуре. И мы вот чётко это прописываем. Потом как-то тоже должны будем дополнительно валидировать уже саму систему, построенную на основании того, как мы её нарисовали изначально. И это было бы круто. Возможно, мы никогда туда и не придём. То есть мы можем строить, строить, если у нас бюджеты безграничные или ещё что-то. Ну, возможно, сейчас и инструментария нету для того, чтобы всё это реализовать. А, и вообще в целом и про C4 тоже можно говорить, что вот есть какая-то модель, её придумали, а популярная она стала не сразу, как её придумали. Популярная она стала тогда, когда чуть-чуть инструменты подошли для того, чтобы её было интересно использовать. Ну а до этого это было просто так интересная теория. А, ну и C4. Приближает ли она нас к архитектуре как код? Я бы сказал, что скорее всего нет. Она она скорее всего предлагает нам вот этот вариант диаграмма как код. В принципе, то, что и предлагал Rational Rows когда-то давно, тоже какое-то описание текстовое, по нему построили диаграммки, мы можем дальше с этим работать. Но C4 нам предлагает, самое главное - это очень большое упрощение той сложности, которая имеется. Вот Архимеate вспомнили. И там достаточно много сущностей. Ну, в мэле, вообще говорят, там 150 сущностей, например, возможно даже больше, там десятки диаграмм, которые раскрывает. Но при этом всё, когда мы будем говорить про C4, мы увидим, что она не закрывает большую часть работы. Поэтому, а, давайте мы сюда запихнём UML. Ну, почему бы не запихнуть сюда UML на определённых уровнях взаимодействия компонентов, если мы это умеем делать? Поэтому это делают в инструменты тоже всё это подтягивается, и как будто бы мы получаем нечто консистентное при описании. А что у нас тут получается? Ну, четыре уровня абстракции и не так много абстракций, о которых которые вообще заявлялись. Самое прикольное то, что вот Саймон Браун, тот, который придумал, во-первых, придумал вот эту C4 модель, потом придумал инструменты для работы с ней. условно удобные. И в этом году выйдет его книга по C4 модели. Я даже не представляю, что там может быть, потому что когда все рассказывают про C4, но это нечто такое, что можно рассказать за 15 минут, а за час освоить и начать это использовать. На самом деле так и есть, потому что тут дальше квадратиков не ушло. Ну, а если опыта в декомпозиции и на в структурировании информации нет, то вообще ни разно неважно, какой у тебя инструмент, ты так или иначе не спрашиваешь, не справишься. Минимум нотаций тут и фокус, скорее всего, на том, чтобы быть всем понятным. Именно поэтому так и называется наша сегодняшняя тема, что мы строим некий язык взаимодействия. Ну и самое важное, очень много людей намного легче воспринимают визуальный визуальное представление тех терминов, о которых мы будем говорить. А, то есть те самые квадратики и стрелочки. И у меня недавно был открытый урок, который назывался Типичная архитектура. Вот там я отдельным слайдом написал, что архитектура - это не квадратики и стрелочки, а вот C4 пропагандирует именно эту историю, но это не точно.

Итак, ээ, что заявляется? А, и заявляется достаточно простая история. У нас C4 призван начать стандартизировать подход к документированию. То есть, если у вас уже есть в компании условный Архимейт, то приходить ко всем и говорить: "Давайте лучше начнём C4", но звучит как-то не очень. А если прийти и сказать: "А давайте ещё в параллель там для того, чтобы быстрее всем рассказывать, что вот есть более упрощённый способ узнать о системе, её немножко с верхнего уровня попроектировать, а потом уйти в что-то такое глубокое, то да, здорово. Есть ещё советы сразу в терминах Архимейта рисовать C4 диаграммы для того, чтобы потом уже развивать полученные результаты на этапе нулевого какого-то проектирования. Поэтому, если сейчас ничего нет, то отличный вариант, чтобы начать что-то делать. Я могу вот сказать, что у нас очень долго ничего не было в компании, связанных с описанием архитектурных решений. Потом был какой-то разброй в виде: "А давайте хоть что-то нарисуем". Что-то среднее между вот тем непонятным lowлеevel дизайном и использованием терминов имеля. А потом потихонечку выбрали чуть-чуть какой-то какой-то структурированности и часть систем описали через C4. Ну, честно, прям какого-то буста не дало. Потому что один из бустов, который здесь заявляется, к нам приходит новый разработчик, мы можем очень легко проводить онбординг, потому что вот смотри, наша система, да, тут всё очень легко. Мы тебя в конкретный домен кладём. Этот конкретный домен взаимодействует со сторонними контейнерами, со сторонними системами. Вот примерно так. Хоп-хоп. Видно, можно отзумиться, призумиться. Всё очень здорово. Мало сущности. Сейчас мы посмотрим, какие из них. И здесь заявляется самое крутое - это иерархичность. Тут ещё очень любят везде рассказывать то, что вот это как карты уровня, мир, страна, город, улица. Ну да, прикольно. такие варианты. И вот эта базовая картинка с сайта C4 модель, который вот здесь есть. Я её специально не включал. А есть вариант в доке сразу писать потом ссылочку на GitHub plant email. Это я зачитаю вам сообщение от Стаса, кто смотрит нас в запись. и отсюда уже C4 тянуть. Ну, в принципе, да. И так вот мы построили некую иерархичность. В каком плане? У нас так или иначе есть вот это проваливание. Есть система, на которую мы смотрим, верхнеуровнево, потом смотрим, из чего она состоит, потом смотрим, из чего состоят эти компоненты, а потом уже где-то там внутри есть реализованная бизнес-логика, бизнес-процессы, взаимодействие каждой строчки кода со сторонними системами. И вот тут уже нужно подходить более осмысленно.

Итак, какие абстракции есть в C4? Тут достаточно простой подход. Система, контейнер, компонент, код, и оно всё включает всё в себя. То есть вот именно так построена эта некая иерархия. Внутри одной текущей описываемой системы может быть несколько контейнеров. Мы разберём сейчас, что это такое. Каждый контейнер состоит из компонентов, а компонент пишется на каком-то коде. И вот в этом коде уже нету C4 на он, мы в него спускаемся, а там всё, что угодно. Итак, программная система контейнер компонент код. Ещё есть очень интересная абстракция человека. Она как будто бы заявляется как абстракция. Как будто бы нет, но без неё нет смысла. Но человека можно заменить на просто потребителя нашей системы. То есть у нас же может быть интеграция наша система. взаимодействует с каким-нибудь клиентом внешней интеграции. Это как человек, но только машина, да? Тут уже есть четыре буквы C, ну, кроме Software System. Потом это заменится на контекст, то есть system contex появится. И вот поэтому так и называется C4. Тут C каждая первая person не вписывается, поэтому очень часто её не указывают. Что нам позволяет абстракция в виде программной системы? Это вообще один из основных способов понять, что мы проектируем какую-то программу систему, что создаём, зачем, какую ответственность она несёт, какое положение её в в мире интеграций. Да, Стас, к четвёртому уровню, что его нету, мы ещё вернёмся. Вот, э, мы можем стремиться к тому, чтобы при описании какой-то конкретной системы граница этой программной системы соответствовала одной команды. Но это здорово, но часто бывает, что это не так. Либо несколько команд работает, либо одна команда над несколькими системами. Тут ещё очень важно, что в зависимости от того, что у нас за абстракция, мы можем явно указывать, что есть какие-то градации людей, занимающиеся проектированием архитектуры. Ну, если у нас стартап, то это понятно, это все. А, а если у нас какая-то такая компания, в которой есть Solution архитектор, enterprise архитектор, то тут мы можем говорить, что вот на уровне системы и на уровне -1 от системы у нас ответственность за то, чтобы всё было работоспособно, лежит на некомтепрай архитекторе. Потом чуть пониже мы спускаемся до Solutiontion архитектора на и в самом низу на коде это вот взаимодействие с разработчиками. При этом всё. Про саму систему мы можем говорить с со всеми стейкхолдерами. У нас тут есть взаимодействие не только с техническим персоналом, но и с бизнесом, с продуктами и так далее. Э, что вот это такое за картинки справа? Это те стрелочки и квадратики, которые условно приняты при написании, при оформлении каждого уровня и каждого, каждой абстракции. В квадратике три строчки, название системы, какие-то какой-то стек технологии, который здесь, и её описание. И стрелочка, которая показывает, как одна система использует другую. Контейнер это нечто, что будет развёртываться в мире микросервисной архитектуре. Бо более-менее понятно, что это такое. Это каждый сервис. Вот мы его запустили, и он у нас заработал. Всё, вроде бы здорово. А при этом всём в контейнеры также помещают приложения, хранилище, брокеры сообщений, очереди разновсякие. Кэш, наверное, будем использовать как хранилище. Тут немножко поменя цвет. Это уже такой посветлее синий. Ну, либо это рекомендуемые цвета. В целом сам Браун говорит, что у меня агностик ко всему подход. То есть неважно на какой нотации мы описываем, неважно какие цвета применяем, что хотите, то и делайте. Разукрашивайте, как вам удобно. И главное, чтобы было понятно. И это очень круто. Ну, есть вот такой подход, когда мы чуть потемнее нарисовали систему, чуть поярче нарисовали контейнер. Это это не дотер контейнер. Очень важно понимать. И, ну, и не контейнер внутри K8S. Это который контейнер D. Это просто некая абстракция. Мы же сейчас об этом говорим. Это то, что мы можем развернуть, запустить и как-то с этим взаимодействовать. Что здесь у нас может быть? Это разновсякие веб-приложения, мобильные приложения, файловые системы, либо некая бессерверная функция. Вот мы можем к этому обратиться. Оно как-то запустилось и работает. Дальше очень интересный момент - это компонент. И в целом компонентов может и не быть, на самом деле, если у нас контейнер вот больше ничего под собой внутри не подразумевает, но стараются как-то выделить, чтобы было красивенько. То есть вот у нас есть какое-то приложение, да? Оно тут он же тут указан, да? Ну вот веб-приложение, оно включает в себя какое-то IP, какой-то рендеринг, какую-то бизнес-логику. Давайте это всё разнесём на разные компоненты. Но в целом это принято воспринимать как некий скрытый за интерфейсом набор реализаций. А компонент не развёртывается самостоятельно. Но не обязательно, что внутри одного контейнера будет несколько компонентов. Может быть и один. Либо наоборот слишком много. Тут мы, э, имеем такой же квадратик, да? Всё очень просто, на квадратиках построено, но появляется ещё значок группы, что мы вот что-то объединяем в пунктирный такой контейнер, чтобы показать, что при приближении на уровень компонентов, что эти компоненты всё-таки принадлежат какому-то контейнеру и не вылазют за его пределы. И всё с абстракциями всё. А вот как они применяются на диаграммах, да? Первая диаграмма - это диаграмма контекста. Она описывает ту самую моделированную систему, которую мы рассматриваем. Тут ээ также нужны категории пользователей, которые взаимодействуют с нашей конкретной системой, которую мы описываем. Сторонние системы, к которым мы можем ходить. При этом всём пользователь тоже может взаимодействовать с этими сторонними системами. И в целом вот эта картинка нам уже проясняет какое-то описание целей и что нам нужно делать. Мы сразу видим те интеграции, которые нам будут необходимы, но что там будет внутри, не очень-то понятно. Мм, и, э, если возвращаться к разговорам о применении C4 для сдач, для решения каких-то архитектурных задачек в виде давайте построим ленту Твиттера, тут тоже будет очень странно. У нас будет человек, стрелка, наша система и, возможно, ещё какая-то односторонняя. Ну вот тут, например, всё, что связано с платежами, у нас уходит, всё, что связано с имейлами, уходит, да, можно это вот туда отдавать, кому она нужна и на какие вопросы отвечают. Основные вопросы, на которые отвечают, какие пользователи у нас используют, с какими системами взаимодействуют, для чего нужны взаимодействия с другими системами. И тут самое главное, что здесь нет никаких технических деталей, поэтому она подходит всем, да. Вот первое такое знакомство с нашей системой. Дальше идёт поинтереснее. Это диаграмма контейнеров. А

Вот тут я написал: "Целевая аудитория — технари". И так получается, что у нас все следующие диаграммы, они как раз-таки под категорию "технари" подходят, потому что тут уже какие-то технические детали объявлены и указываются конкретные технологии. Мы уже можем наблюдать взаимодействие контейнеров.

Ну а чтобы понимать, что мы что-то развернули, вот мы видим, пунктируем тот квадратик, который был до этого. И в неком дизайне, то есть неком проектировании взаимодействия человека с моделью C4, в базу положено, что мы углубляемся в каждый квадратик, сохраняя внешний контекст. То есть вот мы углубились, у нас три вот этих было. Эти три объекта никуда не делись. Мы просто получили дополнительные знания о том, как мы взаимодействуем с ними.

Мы видим, что не все контейнеры у нас, э, лезут в сторонние сервисы. Пользователь тоже взаимодействует не со всеми контейнерами внутри. Контейнеры как-то между собой тут взаимодействуют. Ну и вот тут есть какая-то mobile app, SPA, web application. Ну, грубо говоря, то, что мы могли бы назвать, кстати, клиентами уже к нашему бэкенду, да? То есть у нас не пользователь был бы нарисован, просто вот какой-то набор клиентов и наш контейнер, связанный с бизнес-логикой. Тут у нас указываются потоки данных, что мы хотим получить, какой протокол, что, ну, тут делаем какие-то API вызовы. О'кей, делаем API вызовы. Тут есть какая-то история.

А здесь самое важное, что на схеме контейнеров мы не занимаемся развёртыванием. Это очень важно. Не показывается репликация, шардирование, лоудбалансеры всякие. Мы вот просто строим какой-то такой пайплайн, не думаем о том, что это будет как-то разваливаться. Зато мы выяснили, какие нам контейнеры нужны, как они взаимодействуют друг с другом, куда пользователь заходит, куда не заходит. Мы тут, возможно, здесь мы прокачаемся и увидим сразу какие-то контуры внешние и внутренние. Ну, например, вот это должно быть в закрытом контуре. Тут какие-нибудь ПДНы. И мы это сразу подразумеваем, видим очень хорошо, потому что сразу пытаемся как-то отделить это.

Так что здесь важно? Важно то, что мы здесь уже можем увидеть первую проблему C4. Я её потом ещё повторю. Что когда у нас система простая, тут всё красиво. Если у нас в нашей системе 40 контейнеров, тут будет ничего некрасиво. И улучшить эту красоту C4 никак не позволит, потому что подразумевается, что мы должны вот всё. Либо это будет какой-то промежуточный ход, что мы вот попытаемся объединить контейнеры друг с другом, а потом ещё одна диаграмма контейнеров, которые каждый контейнер, каждую группу контейнеров разбивает. Но это не очень удачно может пойти, а именно на уровне API, с которым мы взаимодействуем. Если мы просто рисуем картинки, то очень здорово. Ну и тут очень здорово, да, если у нас вот это всё описывается как-то единообразно. И именно это позволяет у нас проникать вовнутрь подсистем. А просто на картинках такое тяжело построить.

При этом давно ещё, ну, там года три назад, что ли, четыре, была статья на Хабре, где ребята на уровне Confluence, объектами Confluence построили описание своей системы. Ну, выглядит это так: у нас есть какой-то объект. Этот какой-то объект ведёт на другую страницу, а там новая страница. Она не содержит в себе других элементов, которые выше, то есть которые по задумке автора должны автоматом транслироваться, если мы укажем, что нам нужно при переходе на более низкий уровень повторять передачу вот этих внешних систем, потому что это необязательно, можно опустить. И ручного труда там намного больше, чем если просто картинки менять.

Про компоненты, что мы можем здесь сказать? Тут опять мы уходим вглубь, вглубь конкретного контейнера и видим, что пользователь уже от нас как бы далеко, он от нас скрыт внешне. Ну, мы переходим вот в этот конкретный API application и видим, что тут есть какой-то набор контроллеров. Может быть, вопросик: почему в диаграмме компонентов это является прямо названием конкретного класса из нашего программного кода? Либо мы просто приняли, что у нас есть какой-то контроллер. Это некий термин, описывающий, что нам нужно вызывать для взаимодействия с тем или иным доменом. То есть вот у нас есть домен аккаунтов, есть домен логина и так далее. И при этом компоненты также могут взаимодействовать с внешними системами. Если этот, ну, контейнер взаимодействует с внешней системой, значит, какие-то из компонентов, какие-то конкретные будут с ней взаимодействовать. Здесь мы видим, что не все взаимодействуют с email-системой. И это, в принципе, правильно. Мы уже добрались до конкретного компонента. Увидим ли его связи друг с другом? Тут, наверное, более интересная история для какого-нибудь Solution Architect, для разработчика. А общение мы здесь настраиваем между аналитиком и этими ребятами.

SEO, наверное, вообще тут не интересно, из чего у нас контейнеры состоят. Главное, чтобы данные не утекали и работало всё быстро. Вот понятия здесь те же самые: взаимодействие объектов между друг другом, а, и с внешними системами. В принципе, всё. Техлиду тоже, если есть такая выделенная роль. Ну, вообще не все понимают, что такое техлид. Но есть техлид, да, который начинался с того: "Давайте мы вообще выясним, кто такой техлид". Вот когда синьора некуда было продвигать дальше по грейдам, им всем вешали погоны техлида. Ну и вот заставляли заниматься вот такой историей.

Так, код. А что здесь? А здесь всё, что угодно. А тут у нас могут быть диаграммы. Здесь могут быть диаграммы взаимонаследования классов. А тут могут быть таблички с базой данных. Все зависимости компонентов внутри. Ну, у нас есть какой-то компонент внутри, есть большой набор классов. У них есть зависимости друг от друга, есть зависимости на внешние библиотеки какие-то. Ну и отношения между друг другом. Кто может построить вот эти все истории? Ну, это либо какая-нибудь автогенерация из IDE, либо это никому не нужно. Вот что здесь может быть действительно полезно? На этом уровне могут быть действительно полезны какие-нибудь очень сложные бизнес-процессы, которые можно описать sequence-диаграммами. И вот тут вот самая прелесть вот этого C4. Мы дошли до кода, а там всё, что угодно может быть. И нам единственное, что нужно — это чтобы инструмент визуализации, который мы используем, позволял это сделать.

Так, это то, что заявляется и что можно было услышать в любом другом базовом рассказе про эту модельку. Есть ещё дополнительный набор диаграмм, который позволяет чуть-чуть улучшить. И кажется, что вот этот набор диаграмм, он возник после того, как началось первое тестирование этой модели. Ну, до этого всё было. А диаграмма, да, вполне валидно её сюда запихнуть в код. Почему бы нет?

Landscape-диаграмма показывает место проектируемой системы в общей системе. То есть до этого у нас был какой-то один квадратик, с которым мы взаимодействовали. Теперь у нас появились дополнительные квадратики, которые мы назовём внутренние системы нашего предприятия. Также могут появиться дополнительные внешние системы, с которыми мы не взаимодействуем. Для чего нужна у нас landscape-диаграмма? Для того, чтобы вообще понимать, а где мы находимся? А уникальные ли у нас пользователи или эти пользователи ещё взаимодействуют с какими-то системами? А какие есть внешние? Но вот это можно было бы назвать чем-нибудь вроде карты микросервисов, например. Вот мы так вот красиво всё нарисовали. Но вопросики, да, если у нас их несколько тысяч, как это всё здесь уместить? То есть вот мы нарисовали какую-то систему, объединили наши микросервисы, которые были бы на уровне контейнеров, в какие-то разумные рамки, получили несколько сотен вот таких систем в зависимости от той организации, в которой у нас будет разработка. Это могут называться, например, вертикали или ещё как-нибудь. И вот мы это здесь изобразили. Ага. Всё. Здорово видим, можно использовать. А, ну и подписали вот эти все стрелки между пользователем и системой. Ну, по факту получается, что это я вернул контекст-диаграмму, чтобы рядышком показать, что четыре квадрата из неё отображаются здесь же. Мы увидели что-то более красивое. И диаграмма вот этих ландшафтная. Что это за шаблон? Это с картинки с официального C4 Model сайта. Я думаю, что это просто тема для Structurizr, где описано, что всё прозрачное. И вот пиши какими, разукрашивай какими-то цветами и так далее. Возможно, даже это не на Structurizr был, а руками нарисована.

Вот диаграмма взаимодействий. Здесь мы просто пытаемся изобразить уже взаимодействие элементов, когда у нас происходит некий бизнес-процесс. До этого у нас было статичное отображение нашей системы. Теперь у нас есть какой-то процесс. Как по мне, это вообще, ну, это присутствует в книжке, допустим, да, но не А там нет такого шаблона. Ну, может быть. Так и призвано лечить те недостатки модели C4, которые сразу проявляются, да, то, что у нас есть какое-то статическое отображение, а все процессы у нас так или иначе вот пошаговые. Поэтому давайте рядышком где-нибудь сделаем другое View. Оно как бы будет внутри C4 модели, но просто её расширять. Это хорошо, что починили этот момент и можно это использовать. При этом всём не обязательно это, чтобы оставалось на C4. Это может быть уже на уровне других нотаций, которые мы с вами уже все назвали.

Deployment-диаграмма. Вот это вот самый кайф. Почему? Потому что она показывает как раз-таки всю схему развёртывания. Мы до этого говорили, что на диаграмме контейнеров мы никак не указываем, как у нас данные шардируются, реплицируются, сколько инстансов нам надо запустить. Есть автоскалирование, нету. Здесь мы рисуем это всё, как мы будем развёртывать. Возможно, появляется вопрос: а зачем нам тогда диаграмма контейнеров? А, ну, диаграмма контейнеров нам нужна как раз-таки для того, чтобы не нагружать людей при проектировании взаимодействия сервисов друг с другом. А вот эта диаграмма деплоя уже закрывает вопросики: "А что нам делать, если что-то недоступно? Где у нас там реплика на чтение? Где у нас реплика на запись? Как мы это будем всё делать? Э, что мы в облаках храним?" Здесь, возможно, появляются какие-то названия уже секретные. Вот Core Banking Live какой-то. То есть на каких ЦОДах мы можем развивать или на каких инстансах в этих ЦОДах. А, ну, ну, ладно, пусть будет в каких сервисах. И, а, до этого нам всё это знание было не нужно. То есть мы чуть-чуть приближаемся к нормальной уже технической реализации той системы, которую мы строим. Отвечаем на вопросы, связанные и с безопасностью, и с надёжностью, но очень сильно усложнено. Да, тут мы сразу видим слишком много рамочек, очень много надо зумить туда-сюда либо иметь какой-то огромный монитор, чтобы это всё видеть. И здесь тоже видно вот эта любая любого, а, проектирования, что пока 10 элементов выглядит сносно, когда будет 100 элементов, ну, это будет условно невозможно воспринять, как оно вообще всё работает.

Так. Про базовое описание мы поговорили, и давайте подведём некие плюсы, связанные с вот этой C4. И вообще, что у нас получается? Получается, что мы приходим к некой стандартизации подхода по документированию, особенно если у нас до этого ничего не было. Мы просто невероятно бустим взаимопонимание между командами. Он второй пункт понятен. Я тут не смог придумать, кому понятен. Пусть будет всем. А мы посмотрели, визуально восприняли, примерно определили, как у нас происходят передачи, управления и потоки данных, и всё очень здорово. А для high-level дизайна очень хорошо. То есть, если мы на контекстах и на контейнерах останавливаемся, даже не уходим в компоненты, то вот мы получаем уже вполне себе работоспособные артефакты. Ну а дальше, когда нам нужно будет уже, возможно, решить задачи конкретной реализации взаимодействия внутри контейнеров, можно уже углубиться. Вот. Но тут нужно согласие всех, потому что если мы говорим, что давайте внедрять C4, все такие: "Ой, это нужно работать". А, и в целом в разного уровня командах стартапских, э, позволяет достаточно быстро набросать вот эти два первых уровня. С третьим, да, могут возникнуть проблемки. А подходит, ну, можно попробовать блеснуть на интервью по системному дизайну. Я просто натыкался на один раз или несколько раз на мок-интервью, и там человек такой: "О, давайте я сейчас по C4 вам раскидаю здесь всё". Но это круто выглядит. Вот, как я и говорил, первые два уровня что-то там нарисовали, три стрелки, а дальше всё это уходит вот в то, что мы видели в самом начале. То есть прямо хорошо сделать за час чёткий зум туда-сюда, конечно же, не получится.

Ну и мы приблизились. Первый вариант может быть в каком-нибудь условном Draw.io, в Miro, даже там где ещё. То есть это просто картинки. Дальше мы поймём, что надо это как-то поддерживать, обновлять, и увидим, что есть инструменты, которые нам предоставляют некий DSL, по которому мы можем построить вот эти диаграммы. И в целом у нас два основных инструмента: PlantUML и Structurizr, который нам позволят что-то сделать с этим, мм, с тем DSL, который мы нарисовали. Э сейчас какие-то планёрки запущу. У Стаса, наверное, их будет больше, потому что он постоянно с этим работает.

Так, минусы, да? Ну, с минусами всё очень понятно. Как только у нас становится очень много контейнеров, нам тяжело видеть эту мешанину, потому что, э, тут нет никакой разбивки на уровне, как предоставляет, например, TOGAF. Вот, ээ, ээ, в курсе у нас отдельное занятие по TOGAF. В курсе System Design, где мы вспоминаем про C4, у нас отдельные занятия по ArchiMate и про Arch42. Вот. И и там, и там есть вот C4. Можно кратко о нём вспоминаем сегодня по дольше. Нет никаких бизнес-процессов, условно лечится диаграммой динамической диаграммой и какими-нибудь sequence-диаграммами на уровне кода. Да, для тимлида есть занятие по TOGAF у нас в курсе в программе и ограниченный набор отношений. Тут мы видим одну стрелку. Можем, конечно же, придумать. А давайте стрелки будут разные. Ну непонятно, как с этим решаться дальше, да? То есть если это руками что-то нарисованное, ну, наверное, получится. А если теми инструментами, которые заточены на то, чтобы рисовать C4, а то эти инструменты могут сказать: "Мы не мы не умеем рисовать разные концы у стрелок". Как это сделано в ArchiMate, и это будет что-то означать. А, но среднему уровню, допустим, разработчика эти стрелки ничего и не говорят. Это я вам честно скажу, как разработчик. Уже пришедшая стрелка в квадрат говорит что-то, а какая там, неважно.

Давайте посмотрим, когда стоит применять C4, когда это будет лишним. От, в принципе, у нас два основных. Это предварительное проектирование, а может быть ретроспективное документирование. То есть мы вот уже систему сделали, а потом такие: "О, а что мы там наделали? Давайте зафиксируем и чтобы вот оно осталось". Но так как уже всё сделано, много сил тратить не хочется. Поэтому самым простым таким инструментом воспользуемся, который потом будет давать какие-то ответы, например, при онбординге, при попытке починить. Но тут самое важное — это как и с документацией, как и с любыми другими инструментами. Это нужно сделать так, чтобы было актуально. Позволяет очень хорошо сделать обзор системы для всех команд, адаптировать новых разработчиков и решать вопросы, связанные с технической коммуникацией, а друг с другом. Потому что вот те уровни, которые описывают взаимодействие разных контейнеров, тут мы можем долго искать в иерархии нашей организации, а как у нас контейнеры мапятся на людей для того, чтобы с ними взаимодействовать. Но в какой-то момент у нас получаются и зоны ответственности, и зоны влияния на те или иные продукты. Но нету никакого инструмента, да, чтобы мы поставили там какие-нибудь кружочки и говорили: "Вот поэтому вопрос ходить к Маше, а вот по этому вопросу ходить к Антону".

Вот. Теперь нотации, которые нам будут помогать, когда мы хотим делать что-то другое. Например, мы хотим детальные контракты API. Например, мы хотим какие-то важные алгоритмы прописать. А тут мы используем UML. И, как я уже говорил, можно спокойно запихивать его как артефакты внутрь C4. У нас какие-то сложные распределённые системы, а, финтех там какой-нибудь, то нам вот этой простоты будет не то, что недостаточно, она будет не способна нас защитить. Поэтому придётся знакомиться либо с Arch42, либо с ArchiMate, и там уже рисовать более такие изощрённые схемы и связи с сервисами, которые затрагиваются при изменении какого-то конкретного сервиса. Вот у нас появляется какое-то новое новый закон, и мы сразу должны определять, какие сервисы нам нужно поизменять, чтобы всё чётко прошло. А ADL тоже можем использовать в хорошо регулируемых. Так. Тут какие-то пункты, связанные с ArchiMate, когда мы что-то делаем на долгие годы вперёд, разрабатываем стратегию, роудмапы и соответствие требованиям. Но да, то есть мы видим, а что если мы даже не осилили C4, то ArchiMate нам будет осилить ещё сложнее. А тем более осилить в том плане, что внедрить в постоянное использование. Поэтому можно внедрять потихонечку, может быть, даже какими-нибудь партизанскими методами.

Итак, если у вас есть сейчас какие-то вопросы, то можете их задать. А я покажу две штуки. Первое — это когда я пытался на своём компе что-то поиграться. Нужно нарисовать в нотации C4 в Structurizr. Это продукт тоже от Брауна. То есть вот эта его моделька связана с тем, как углубляться до кода. >> Что ещё? >> Так. А где он? Я его должен был стереть. >> У меня был такой слайд, я его убрал, но я его заменил на вот этот. называется. >> Так. >> Вот я столкнулся вот прямо с такой же проблемой, вот как здесь написано. И решается она очень просто: нужно выдать права на папку. А тот Structurizr запускается из Docker-контейнера, обращается к локальной папке. А >> Сейчас, секунду, подождите. >> Так, а как тут микрофон выключить? Это баг подготовки материалов. Да. А >> Я хотел сначала весь блок назвать, что ещё использовать вместо C4 и как его расширять, потом переименовал. А что ещё в заголовках осталось? Вот. Да, теперь придётся с этим жить, с этим позором. Последний мим оказался, там мышь позора приходит. Так, решили эту простую проблему, как запускать Structurizr. Вот он запущен. Какие-то кучи ошибок. Вот такой красивый шрифт. Всё. Делать почти ничего не надо. Просто Docker-compose up, потом вот эта команда для запуска, и вот на эту папку надо выдать 777 права, чтобы кто угодно мог её читать. А что делать дальше? После того, как мы увидели, мы можем открыть какой-нибудь workspace без подсветки кода, потому что я не скачивал никаких плагинов. И вот мы начинаем проектировать на нотации Structurizr. Описываем, что у нас есть какой-то workspace. Говорим, у нас есть моделька. И в целом внутри одного файла мы можем описать всю нашу систему. И это, наверное, даже очень комфортно, потому что не надо искать, как называется в других файлах та или иная сущность. Мы описываем клиентов нашей системы, а назвали систему, ещё одну систему назвали. Так, потом начинаем описывать контейнеры, компоненты, из которых строится наша система. Связи, вот эти самые relations. Ну, тут название объекта из того, что мы назвали дальше выше стрелочка, что и что делает эта стрелочка. И если бы это была настоящая архитектура как код, то мы могли бы писать вот ещё и, например, какие-нибудь так, почему Structurizr, а не PlantUML? А я оба сейчас инструмента покажу. Вот что-то написали. Связи на уровне C1, на уровне C2, на уровне C3. И теперь начинается самое прикольное, да, это как мы строим вьюхи. Для того, чтобы внутрь проходить, мы говорим, что хотим построить C1, мы хотим построить контейнеры. И тут вот что мы включаем, что не включаем. Ну вот звёздочка, всё включили. Поэтому, когда мы пропускаемся, тут можно включать только те компоненты, которые, например, с нашей системой взаимодействуют. Так, потом мы А вот как звучит вопрос Стаса: "Почему Structurizr я выбрал?" Я не выбрал Structurizr. Просто его советуют как знакомство посмотреть. Да, PlantUML здесь намного более универсален, потому что в нём тоже есть построение C4 и можно другие диаграммы строить. А так, а в PlantUML есть авто? А, ну да, я просто не особо смотрел, как зумится из одной диаграммы в другую, потому что там всё-таки вообще всё настроено на то, чтобы просто диаграммки получить и свалить. Так. Так. И возможно, если хорошо натренировать модельку, то из одного в другой переносить достаточно легко. То есть мы как-то описали контекст, а, и туда переходить. D2. Да, я на него натыкался, но так как рисование архитектурных схем — это не моя основная деятельность, то я на него особо не смотрел. Ещё описали компоненты. И вот здесь можно описать вот те самые темы, чтобы было красивенько. Так, тут кайф то, что можно что-нибудь написать, там убрать. Дождаться, когда всё зависит. Нет, нафиг. Обновить вот этот файлик и получить вот этих набор вьюх, которые у нас тут есть. Мы пришли на так C1 уровень. Видим, что есть вот какой-то пользователь. Здесь всё подсвечивается круто. В сервис заказа еды. Вот у нас эти три пользователя. Так как тем никаких нету, поэтому они квадратные. А так, конечно, нужно разукрасить, что вот система у нас вот это внутренняя, вот это внешняя, а это три персоны, которые персоны хоп, отзумились и сразу нам предлагают, куда мы хотим проникнуть. Ну пусть будет C2 контейнеры. Ну и тут ужас, ужас уже начался. Как с этим работать, непонятно. Постоянно доскролить, стрелки пересекаются. Ну, в целом мы как раз-таки получаем то, что и хотим. Вот то, что здесь понаполняли, как какие инклюды сделали, туда и вошли, прописали. Какой у нас Так, это контейнеры, но тут компоненты, да, пошли. А с какой хранилкой кто у нас работает? Вот какие-то репозитории. Сервис заказов, приложуха, которая с бэкендом взаимодействует. И вот мы всё подписали, всё круто, удобно, осталось только разукрасить. Другие вьюхи посмотрели, что это такое. А это мы видели. Вот. Вот контейнер, да, наша система. Тут пользователь куда-то тут туда-сюда. Я просто хочу посмотреть, а что нам сделать, чтобы Так, а у меня редактор завис. Я не знаю, как его вырубить. О, вот так вырубить. Так, ну да, стрелки можно гнуть, а только потом при построении всё равно ж оно не сохранится. Так, ну сохранится, да, если нажать где-то сохранить. Так, вот у нас есть какая-нибудь C2 Presentation View. Давайте мы из него что-нибудь уберём в, например, базу данных. Чик-чик. Да, также тут комментарии представляются. Так же как UML, да? Обновили, нажали F5. Оп, всё, базы данных нет. Круто. Поэтому мы можем отфильтровывать, что нам нужно. И вот тут вот именно и появляются вот эти возможности инфраструктуры как код, что мы можем фильтровать для разных вьюх ту часть изначально построенной архитектурной модели, которую мы построили. То есть мы хорошо разделяем у себя представление нашей модели при помощи блока View и изначально её построение для того, чтобы убрать то, что нам не нужно, куда-то спрятать и радостно с этим быть.

Так и по PlantUML тут примерно то же самое. У меня просто два примерчика из того же самого домена. И тут также описан некий person, внешняя система, текущее ограничение системы. Ну, в смысле, контекст мы описали так, это C3, пусть будет C2 поменьше. Тут несколько персон, несколько систем, наши компоненты. и описываем отношения друг с другом. Вот Павел говорит, что графический интерфейс легче. Да, тогда мы не Но мы так не получаем те преимущества, которые тут заложены в быстрой перегенерации всех. Я не знаю, почему мы не видим картинку. Он пытается так. А может надо нажать? В общем, я нажимаю Alt+D и ничего не происходит. Значит, но я на другом компе, я на рабочем компе видел здесь картинку. Она примерно такая же, как Structurizr, только хуже. Там ещё больше пересечений. Вот получается как-то вот так вот. И придётся настраивать. Вот Марат говорит: "Можно ли в таком коде хранить версии в Git?" Да, это одна из целей. Одна из целей архитектуры как код, ну или хотя бы диаграммы как код, как часть документации, как код. Это видеть версионирование. То есть мы можем проследить, что, ээ, изменяется в нашей системе со временем. То есть вот мы что-то зафиксировали, договорились, потом хоп, вышла новая документация. Что там, что нам делать? Либо картинки друг с другом сравнивать, либо сразу мы можем увидеть в истории коммитов, что добавилось отношение, добавилась какая-то, добавился новый контейнер и так далее. Графер надо настроить. Ну, возможно, JVM с боит. Ну, как вариант, особенно как вариант того, что у меня, кажется, Java вообще ещё пока не стоит. У меня в понедельник слетела операционка. Да. Значит, действительно, JVM с боит методом неустановки. Так, DPI 300, кубики можно тягать, стрелки гнуть. Так, что потом делать с этим кодом? Со временем придётся выбросить тогда, когда наша система полностью будет ему не соответствовать. А сервер Plant с инклудами глючит постоянно. Код проще доработать, версионировать. Вот. Хорошо. Вот мы с вами достаточно оперативно, я планировал ещё оперативнее, разобрались в этой теме. Если есть ещё какие-то вопросы, пожелания, то задавайте. А пока вы не пришли в себя, я вам расскажу про курс. Значит, мы с вами были с открытого урока "Системный аналитик и управление командой". Когда-то прямо с с уроками с курса приходили. Мне это не нравится. Я готовлю уникальный контент под открытый урок. Ээ что у нас тут имеется? У нас есть ссылочка на то, чтобы посмотреть на курс. Ну, так как вы зарегались, то вы знаете, где она находится. Программа курса. Сейчас посмотрим её повнимательней. Ой, это я и ещё три прекрасных человека. И там справа будет ещё больше. Вот всё у нас основная продажа — это онлайн-вебинары. То есть тогда, когда можно прямо во время рассказа преподавателя задать вопросы, уточнить, что неясно. Но ещё и есть, конечно же, вот эти чаты поддержки, в которых состоят все преподаватели, в которых иногда есть группы с очень активным общением. Иногда есть группы, в которых ничего не происходит, но тут зависит от чего-то. Можно ли ссылки из презентации кинуть в чат? Да, конечно же. 29 июня здесь всё начнётся. Будет ещё один открытый урок. Денис расскажет про монолиты и микросервисы. И давайте подведём итоги. Так, сама презентация и все ссылки с неё вот по этой ссылочке. Надежда. Так. Меня можно найти тут. А мы с вами сегодня посмотрели на все абстракции C4, на все диаграммы, которые она предлагает, когда удобно, когда неудобно ей пользоваться. И поэтому в целом О, а что это такое? Странная ссылка. Мы с вами всё обсудили. А что у нас в программе? Самое интересное про работу с командой, так как курс про тимлида. Тут небольшой блок, связанный с налаживанием контакта с разработчиками, чтобы говорить, как они, вот этими умными словами, типа "паттерн", "инкапсуляция" и ещё какие-нибудь. Вот дальше хороший блок по архитектуре систем и данных. Я сюда приду рассказывать. Остальные темы, такие как TOGAF, монолиты, микросервисы, проблемы high-load систем, безопасность — это я тоже могу рассказать, но меня не зовут. Отдельный блок про документацию, про автодокументирование и про "документы как код" и так далее. Так и проектная работа тоже что-то крутое. На некоторых курсах она начинается с первого занятия, у нас на курсах по .NET. Так на множество количество курсов в последний месяц. Какая-то большая работа, она охватывает все домашки, проект отдельный, а подводит такую хорошую черту под теми пятью месяцами, которые вы провели. Что такое 5 месяцев? Это два раза в неделю, одна или две недели каникул, то есть когда нету на этой неделе занятий. Встреча в какое-то время. Так-так-так. В общем, где-то на этом лендинге есть. А вот по понедельникам и четвергам в 20:00 по Москве. Крутец. Вот мы с вами всё и узнали, всё закончили. Спасибо всем, кто дождался окончания. А был рад с вами познакомиться. Можете приходить в личку всех чатов, если будут вопросы по любой теме, в которой я разбираюсь и не разбираюсь. Существует ли код First? Да, конечно, это и есть код First. А, нет, это же не код First, да? Код First — это когда наоборот, мы сидим, фигачим код, а по нему что-то возникает, наверное. Нет. А вот, знаете, Стас, когда-то давно можно было по рефералке залететь, и всем было выгодно, а теперь этого нету. Прямо сейчас операционная эффективность водителя. Ничего себе. О, спасибо, Стас. От человека, который всё знает про C4, это особо приятно услышать. Вот давайте посмотрим на ADL, чтобы было повеселее. Вот это вот такие ужасы с самолётиками. Смотрите, да, оно даже не открывается. Это вот, знаете, это вот прямо тот Computer Science, который был в семидесятых-восьмидесятых. Тот крутой, неподвижный. Блин, тут нет ни одной картинки. Ужас какой. Да я когда вот IDEF увидел, я аж чуть чуть не прослезился, что это те самые диаграммы из университета. Тоже подумал, неужели их кто-то ещё использует? А ещё прикольно, вот тут вот есть в перечислении нотаций, как оно там сейчас BFC, CFC. Я смотрю на эти буквы, думаю, блин, что-то знакомое, не помню что. А, и так, странно, где все ссылки. Перешёл на первую попавшуюся ссылку, и мне предложили заплатить денег, чтобы узнать, что такое. Вот и всё. Заходи и узнаешь, что такое Basic Flow Chart и Cross Functional Flowchart. А нет, давайте закончим всё-таки вот на этой картинке, чтобы она была в конце видоса. Всем отличного настроения. Если вдруг хотите стать .NET разработчиком, приходите и сюда тоже. И по проектированию систем у нас тоже есть о чём поговорить. Всем отличного вечера. Satle 05. Блин, а я не знаю, что это такое. А это значит пятипроцентная скидка. Можете попробовать ввести 15, и, может быть, пройдёт пятнадцатипроцентная. Это так было перед Новым годом. Циферки менялись. А где чат? А он тут, да, в презентации. Раньше в презентации был промокод, а теперь нет. А, блин, знаете что? Я совсем забыл. Тут же есть классная вещь. Это пройти опрос. А-а, я забыл вставить презентацию, поэтому забыл вам сказать. А вот ссылка на опрос. Очень всем важно, как мы тут что рассказываем. Ну, говорят, эта ссылка всё равно на почту приходит. Теперь вообще все необходимые действия я совершил, да? Ну, тем более всем спасибо за такое приятное общение. Как минимум то, что оно было.