Описание архитектуры, очень созвучное моему внутреннему восприятию этого понятия. Я отношусь к налагаемым архитектурой ограничениям как к физическим законам, которые определяют возможные и допустимые взаимодействия между элементами и на которые можно полагаться при анализе и прогнозировании поведения системы.

Архитектура архитектуры (физика явления)

С точки зрения физика архитектура объясняется просто.)

— Система имеет некоторую энтропию (мера хаоса).
— Эта энтропия тем выше, чем сложнее система, то есть чем больше система содержит элементов.
— Высокая энтропия порождает высокую неопределённость. Мы не можем предсказать, как поведёт себя система в дальнейшем, и чего нам ждать от неё.
— Устранить риск можно, получив информацию об элементе системы. Чем больше информации мы имеем, тем меньше у системы шансов «взбрыкнуть».
— Однако для полного контроля над системой нужна вся информация об её элементах и об элементах, с которыми система взаимодействует. Это трудно достижимо.
— Решение: связываем элементы системы, подчиняем их нашим правилам. Чем меньше у элементов степеней свободы, тем предсказуемее их поведение.
Получившийся набор правил нарекаем архитектурой.
Если система реализует архитектуру, то её энтропия снижена и вместе с энтропией смягчены риски.

Ну а архитектор в этом случае — борец с энтропией.)

Сколько копий сломано в спорах про правильную организацию и декомпозицию кода. Тут намешаны и архитектурные слои, и ограниченные контексты, и между микросервисами и монолитами...

Мне же видится, что все подходы - это проявления встреченного когда-то в книге по объектно-ориентированному проектированию простого принципа "непрерывности" кода.

Еще помните что такое непрерывность? вот это самое - "для любого эпсилон больше нуля существует дельта, такая, что ...". Эта нудная и формальная математическая формулировка скрывает простую суть: у непрерывных функций малые изменения параметров приводят к малому изменению значения. У "непрерывного кода" похожее свойство - малые изменения требований приводят к малым изменениям кодовой базы.

Казалось бы, что может быть проще? Но, как говорится, есть нюанс. Что такое "малые изменения требований" каждый стейкхолдер понимает по своему. Для кого-то это смена используемой СУБД на другую (подумаешь, изменилась одна строчка в ТЗ!) - и вот для обеспечения непрерывности кода нужно использовать СУБД-независимую прослойку и добро пожаловать в ORM. "Малое изменение" в другом случае - это изменение атрибутивного состава сущностей - и вот мы уже на пути генерации интерфейсных форм по описанию модели.

Разбиение кода на части, компоненты, модули (что, собственно, и является существенной частью архитектуры) похоже на переборки на подводной лодке, это препятствия на пути распространения изменений. Если разбиение сделано удачно, т.е. топология разбиения кода соответствует точкам концентрации изменения требований, то изменять код относительно несложно, изменения локализуются в модулях. Проектирование такого разбиения невозможно без понимания динамики изменения требований, которое возникает только при глубоком погружении в предметную область. Чтобы сделать толковую архитектуру мало знать какие требования к системе предъявляются сейчас. Важно уметь предугадывать, какими они станут потом, или хотя бы в каких местах будут меняться.

Выделение ограниченных контекстов в DDD и разбиение кодовой базы на части по контекстам тоже, в общем-то, базируется на этом принципе, но идет еще немного дальше. Грамотно построенные границы контекстов ограничивают распространение изменений не только кода, но и требований. Теоретически, изменения в одном контексте не должны бесконтрольно расползаться по соседним контекстам и, соответственно, не затрагивать соответствующую кодовую базу. Хотя, честно говоря, вблизи такого идеального разбиения я пока не встречал 😉.

Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉).

Вот смотрите:

Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.

Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.

После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.

После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов.

Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)

И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.

Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно).

Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает:
— А вот у вас герой выходит из здания, а сумка при нём?
— Какая сумка?
— Ну, две сцены назад у него была кожаная сумка, она сейчас с ним?

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

И сценарист начинает переделывать или уточнять сценарий после всех замечаний.

Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!

Годная статья про GIN индексы в #PostgreSQL
https://pganalyze.com/blog/gin-index

Давно хотел разобраться как оно работает, да все руки не доходили. Оказалось, что все не так уж сложно. Но интересно.
Прямо вспомнились 1990-2000-е годы, Cognitive Technologies, Электронный Архив (!) Евфрат, организация индекса в иерархической СУБД НИКА...

Имеем: Система А обращается к системе B, которая состоит из N экземпляров с отдельными урлами (B1, B2, B3 и т.п.)
Если мы точно знаем, на каком экземпляре обрабатывается запрос, то можем обращаться напрямую к нужному экземпляру, например A -> B3.
Но если точно не знаем, то есть система M, которая по параметрам запроса умеет определить правильный экземпляр B и адресовать запросу туда, куда нужно. Т.е. запрос идет так:
A —[запрос]—> M —> {B1 | B2 | B3 .... }. И, соответственно, есть накладные расходы на вычисление правильного экземпляра, т.е. такой запрос, по идее, должен выполняться дольше, чем прямой.

Однако, если верить замерам времени выполнения на стороне системы А, то для одного (!!WTF??) из экземпляров B ситуация ровно обратная - прямые запросы выполняются примерно на 100 мс дольше чем через промежуточный маршрутизатор. Для остальных экземпляров ситуация обратная (т.е. ожидаемая).

Почему может быть такой эффект?
Накидайте гипотез, будем проверять.

Вдруг вы еще не слышали - с 14 по 18 октября пройдет онлайн-конференция Podlodka Techlead Crew, посвященная вопросам проектирования надёжных систем.

Мне лично показались потенциально интересными:
- стартовый доклад про ключевые архитектурные принципы обеспечения надёжности (Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) )
- доклад про фичетоглы от Николая Тимонина. Тема вроде бы уже не новая, но интересно послушать прикладной опыт.
- Подкупает название доклада Александра Агейченко «Надежный как кирпич» и цифры 99.9999% в описании.
- Интересно послушать рассуждения Филиппа Дельгядо про надежность взаимодействия сервисов, на которую заметно влияет кафка между ними.

Да, честно говоря, всё бы послушал, если удастся выбрать время :)

Если тоже соберетесь - то организаторы подвезли промокод на скидку в 500р : techlead_crew_7_SeusjW

— — — — — —
https://podlodka.io/techcrew

Что такое Eventual Consistency и как с ней бороться.

Когда процессоры были большими, базы данных - маленькими, а приложения - монолитными (а то и вообще пользовательскими 😉) все активно топили за строгую согласованность. В самом деле, удобно - целостность данных обеспечивается, что один записал - то другой и прочитал, красота, да и только. Тогда придумались транзакции, ACID и прочие премудрости, сводящиеся к тому, что Strong Consistency - это хорошо и правильно.

Однако время шло, процессоры в размерах уменьшались, а базы данных и приложения росли, росли и постепенно перестали помещаться в маленьких процессорах, стали распространяться на несколько узлов и превратились в распределенные. Это было удобно, много маленьких приложений лучше обрабатывали большие потоки данных, чем один большой. Если одно из них сдохнет - никто и не заметит.

Хотел коротко, не получилось, пришлось освоить telegraph.
Продолжение тут https://telegra.ph/CHto-takoe-Eventual-Sonsistency-i-kak-s-nej-borotsya-11-09

Случайно занесло на #softweekend. Спасибо родной компании за билет.Глоток свежего воздуха социализации после заточения удаленки ;) Доклады, правда, послушать почти не получается пока, зато получается много потрепаться 😉. Если кто-то ещё из подписчиков тоже тут - заходите пообщаться.

Организаторы придумали интересную механику нетворкинга. Каждому участнику конференции выдают бейдж. Но дают не его бейдж, а первый попавшийся из общей кучи 😜. А дальше начинается игра "найди себя", причём поначалу обмен неравноценный. Я встретился со своим бейджиком только на четвёртом обмене. Но каждая итерация - это повод познакомиться и обменяться хотя бы парой слов. Ну или не парой, это уже как получится.

Больше всего голосов набрал вопрос "как из разработчика стать архитектором", так что начнем с него.

Вообще говоря, это, конечно, зависит от контекста ;-) Наверняка есть много самых разных способов и траекторий, я могу лишь поделиться своими соображениями и рассказать про свой путь.

Я старался покороче, но все равно получилось длинновато. Я не верю, что кто-то будет читать лонгрид, поэтому будет несколько постов.

Поехали!

Итак, "я разработчик, хочу расти в архитектора, куда смотреть, что изучать?"

С точки зрения здравого смысла ответ на этот вопрос очень прост. Чтобы стать архитектором, нужно научиться делать то, что делают архитекторы. А для этого сначала придется разобраться, чем же, все-таки, занимаются архитекторы. А дальше уже можно будет подумать, как этому научиться.

Со стороны разработчиков часто может показаться, что архитекторы - это такие странные люди, которые приходят со своими странными и не всегда понятными идеями и говорят, как нам надо жить и что мы должны делать. И это иногда, наверное раздражает. Чем же занят архитекторы и откуда у них берутся идеи и почему компании стремятся их завести?

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

Рассмотрим, к примеру, задачу вывода нового продукта на рынок. Все мы считаем, что делать надо хорошо, а делать плохо - не надо. И потому нужно делать программы с использованием современных фреймворков, применять правильные паттерны декомпозиции и абстракции, а всяким легаси-системам место на свалке.

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

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

Или другая, не менее частая история.

Есть компания, у неё есть работающий, прибыльный бизнес, в основе которого лежит устаревающая (или уже устаревшая) информационная система. Есть понимание, что да, систему пора менять. Но как это сделать не ломая и не останавливая бизнес?

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

И задача архитектора новой системы состоит не только в том, чтобы спроектировать новую систему для решения бизнес-задач, но заложить также этапность разработки, запланировать поставки компонентов системы с учетом плана миграции бизнес-процессов, с учетом бюджетов и сроков проекта по замещению. Чтобы не оказалось, что да, мы разработали 90% функционала, но при этом ни один бизнес процесс до конца не реализован и не работает...

Как видно из примеров выше, чтобы выполнять свою работу хорошо, архитектор нужно, во-первых, худо-бедно разбираться в том, как работает бизнес вокруг систем, которые он проектирует. Он должен понимать как зарабатываются и на что тратятся деньги, в каких бизнес-процессах участвует программный продукт и какое влияние на них оказывает. Кто и зачем использует систему, и почему это делается именно так. Не обязательно лезть глубоко в детали, от архитектора никто не ждет инвестиционных планов и подробных финансовых отчетов. Но общее понимание должно быть.

По себе скажу, что переход из одной предметной области в другую всегда действует как холодный душ. Я много лет занимался электронным документооборотом и архивами. Потом какое-то время погружался в контекст проектного управления. После меня на несколько лет вынесло в информационную безопасность - идентификация, аутентификация и управление доступом. Следующим интересным и важным этапом была работа по разработке систем автоматизации зданий. Сейчас я работаю в области автоматизации электронной коммерции.

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

Во-вторых, архитектор - это, все-таки, инженер, и потому, чтобы выполнять свою работу хорошо, необходимо владеть навыками проектирования технических решений. Для этого нужно иметь обширный (или хотя бы достаточный) арсенал технических решений с пониманием их особенностей, ограничений, возможностей и последствий.

И вот, наконец-то, мы подобрались к ответам на исходный вопрос - как и чему учиться.

По технической части все достаточно просто - есть просто огромное количество книг, статей, роликов, курсов, да и просто документации к разным техническим продуктам, надо просто читать, слушать, смотреть, пробовать, экспериментировать, и постепенно накопится достаточный объем знаний и умений..

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

Есть мнение (и не только моё), что этот процесс сильно ускоряет владение навыками системного мышления, поскольку задает определенные рамки и рельсы восприятия, позволяющие фокусироваться на важных вещах, помогает задавать правильные вопросы, обращать внимание на существенные аспекты ответов.

Само по себе системное мышление - не самая простая дисциплина. Когда читаешь книги или слушаешь лекции, то кажется, что все просто и очевидно. Проблемы начинаются, когда пытаешься применить предлагаемые модели к окружающей реальности. Тут оказывается, что все не так уж просто и не очень-то очевидно. Примерно 4-6 месяцев уходит на то, чтобы научиться смотреть по сторонам "системным взглядом". И не меньше года на то, чтобы получать от этого заметную пользу в реальных проектах. Но могу с уверенностью сказать, что инвестиции окупаются сторицей. Становится легче понимать что происходит в сложных проектах, видеть природу конфликтов и понимать, какие свойства и характеристики системы действительно важны, а на каких можно "сэкономить".

Подытоживая, я бы рекомендовал начинать путь к архитектурной работе со следующих шагов:
1. Прочитать несколько книг, расширяющих мышление за границы технических вопросов.
Мой список must read:
- Цель. Э.Голдратта.
Если зайдет первая - то прочитайте 2 и 3 части, они тоже интересные. Но 1 - обязательно.
- Искусство системного мышления. О'Коннор Дж., Макдермотт И.
- Антихрупкость, Н.Талеб

Понятно, что список не исчерпывающий, но эти книги особенно сильно повлияли на мое отношение к рабочим вопросам - как принимать решения, проектировать решения и организовывать процессы.

2. Пройти хотя бы базовый курс системного мышления,
дальше сами поймете, насколько оно вам заходит.
Самое главное - научиться видеть системы, роли и их интересы в своих рабочих проектах, различать уровни систем, не путать зависимости и вложенность, отличать требования от потребностей.

3. А вот тут, после получения базовых метанавыков мышления можно уже изучать профессиональную литературу по архитектуре. Благо, выбор немалый. Ну, т.е. теоретически можно с этого начинать, но, мне кажется, без первых двух пунктов эти книги покажутся невыносимо нудными и бесполезными :).

А параллельно накапливать технические скиллы и опыт. Старайтесь, изучая или читая про очередной фреймворк или СУБД, обращать внимание не только какой он сам по себе быстрый, надежный, удобный и т.п. а насколько он полезный для решения тех или иных задач. В чем сильные или слабые стороны, по сравнению с аналогами. Пригодится, когда нужно будет обосновывать то или иное архитектурное решение.

P.S. Вспомнил еще книжки про устройство бизнеса. Мне прямо очень хорошо зашли романы Артура Хейли, который живописно описывал работу отеля, аэропорта, завода, клиники. Очень впечатляюще описывается сложный механизм работы большой и сложной системы, состоящей из множества элементов.

Рекомендую для расширения кругозора после освоения хотя бы азов системного мышления. До этого книги будут восприниматься просто как художественная литература, систему не увидите.

Геннадий Круглов в своем канале рекомендует начинать с другой книжки про системное мышление - «Азбука системного мышления», Донелла Медоуз. Тоже хорошо, кстати, можно и с неё начать.