Чистая архитектура и микросервисы

cleanБоюсь, что этот текст выльется в достаточно большое количество букв. Но пишу сюда я тексты нечасто, так что может кто-нибудь его и осилит. Тем более, что использование микросервисов уже достаточно долго сопровождается вопросом: зачем мы это делаем. Несмотря на обилие вариантов ответов (см., например, отличный обзор Nate Schutta (+Matt Stine) Should that be a Microservice? Keep These Six Factors in Mind), вопрос этот задается снова и снова. У меня есть свой вариант ответа. Если говорить просто заключается он в переносе идей Чистой архитектуры Роберта С. Мартина (дядюшки Боба) из мира [монолитных] приложений в пространство распределенных архитектур. Цитата из его книжки Чистая архитектура. Искусство разработки программного обеспечения:

Архитектура программной системы – это форма, которая придается системе её создателями. Эта форма образуется делением системы на компоненты, их организацией и определением способов взаимодействия между ними. Цель формы – упростить разработку, развертывание и сопровождение программной системы, содержащейся в ней. Главная стратегия такого упрощения в том, чтоб как можно дольше иметь как можно больше вариантов.

Можно по-разному относиться к идеям этой книжки. Я даже не стану утверждать, что они всегда и всему подходят. Но небольшую часть из них, прежде чем вернуться к микросервисам, мне придется повторить.
Итак, поехали! Продолжить чтение «Чистая архитектура и микросервисы»

BPMN Slider

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

Продолжить чтение «BPMN Slider»

Воронка инициатив

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

Продолжить чтение «Воронка инициатив»

Аналитики vs. Архитекторы

Рискну поделиться субъективным мнением, надеясь, что его обсуждение не выльется в холивар. Есть много хороших бизнес/системных аналитиков, которым более-менее регулярно приходится заниматься проектированием ИТ-решений. ИТ-архитекторам тоже регулярно приходится заниматься анализом. Причем речь идет не только о технологиях, но, в не меньшей степени, о погружении в предметные области, концептуализации присущих им вещей и операции, конкретных практик деятельности организации. Может быть разделение профессий аналитика и архитектора необоснованно? Думаю, что нет. Я знаю хороших аналитиков, которые не хотят быть архитекторами, а также архитекторов, которые не смогут, да и не станут работать аналитиками. О том, как разобраться в собственных предпочтениях этот текст. Продолжить чтение «Аналитики vs. Архитекторы»

Микросервисы. Обратный билет

Из telegram-канала Архитектура ИТ-решений

Я приступаю к этому тексту с наивным намерением сделать целую серию небольших заметок о современны архитектурах ИТ-решений и разобраться, в первую очередь для себя, является ли переход на микросервисную архитектуру путешествием в один конец. Мне довелось читать достаточное количество историй о том, как та или иная компания вернулась назад из микросервисного безумия, но ни разу я не видел подобной истории собственными глазами и даже не разговаривал с участниками или очевидцами. Предполагаю, что упомянутых выше историях есть определенное лукавство. Обратный билет из микросервисов представляется мне лженаучной фантастикой. Впрочем, безусловно, я вполне могу ошибаться. Если вам хочет поделиться со мной своим контрпримером, то обязательно это сделайте Продолжить чтение «Микросервисы. Обратный билет»

Open Agile Architecture (запись вебинара 5 ноября 2020)

Первые впечатления от нового стандарта архитектуры предприятия Open Agile Architecture™ от международного технологического консорциума The Open Group

Слайды в telegram-канале «Архитектура ИТ-решений» https://t.me/it_arch/946

Коротко об обучении ИТ-архитекторов

Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей. Продолжить чтение «Коротко об обучении ИТ-архитекторов»

Как понять, что вы разговариваете с настоящим ИТ-архитектором

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

Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(architecture decision). Примерно так же, как в свое время Леонард Ричардсон предложил использовать модель уровней зрелости для проверки соответствия API архитектурному стилю REST. Продолжить чтение «Как понять, что вы разговариваете с настоящим ИТ-архитектором»

Микросервисы. Закат хайпа?

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

Но, действительно, тема микросервисов столь долго держалась на первых полосах блогов и в расписаниях айтишных мероприятия, что многие от неё порядком подустали. Я не думаю, что микросервисы, т.е. независимо развертываемые компоненты систем, куда-то исчезнут. Скорее их будет становиться все больше и больше. Но восприятие их, возможно, изменится. Слишком разные по своему характеру и назначению компоненты сегодня записывают в микросервисы. Приверженцы связанных с микросервисами архитектурных паттернов уже не первый год стараются дистанцироваться от этого чересчур туманного, а зачастую и неверно истолковываемого термина. Вряд ли это желание ослабнет. То, что мы называем этим общим термином сегодня, рассыплется на несколько разных понятий. Перечислю основные из них: Продолжить чтение «Микросервисы. Закат хайпа?»