На сайте EventStoreDB нашел транскрипт легендарного выступления Грега Янга, случившегося 10 лет назад. В виде текста оно воспринимается немного иначе. Чем-то похоже на известный 50-страничный CQRS Documents

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

В материалах TheOpenGroup опубликованы не только файл с описанием и archimate-моделью учебного кейса ArchiSurance Case Study, но и сформированная при помощи Archi web-версия модели для этого кейса(правда немного кривая, как и сам Model Exchange File примера)

Начинать смотреть вот с этой вкладки: https://pubs.opengroup.org/architecture/case-study-models/archisurance-html/?view=id-45418

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

Записи прошлогодней конференции Flow появились в открытом доступе: https://youtu.be/Qt26BQXSsvA?si=HX07IvGIOZks206S&t=218

📅 15 марта 10:30 MSK Бесплатный вебинар: Реальная альтернатива микросервисам

Монолит не альтернатива микросервисам! Будь он хоть двадцать раз модульным. Монолит всегда останется единым процессом, который не разделить по серверам... или нет?

Подробности и регистрация: https://mxsmirnov.timepad.ru/event/2803564/

У Фаулера появилось описание наверное самой востребованной техники Перехват событий в рекомендациях Patterns of Legacy Displacement

Причем рассмотрены разные случаи. Если есть такая возможность, то события извлекаются из очереди. Нет такой возможности, то перехватываем HTTP поставив reverse proxy или доработав приложение или воткнув посередине API-gateway. В крайнем случае - триггеры БД (хотя по мне, так это уже перебор, не надо так). Ну и простенький пример перехвата событий с change-data-capture процессом

Ссылка на запись: https://youtu.be/rIr6xIB_x3I

+ слайды

На днях у /thoughtworks проскочила очередная статья про техрадар How to create your enterprise technology radar с набором не очень очевидных мыслей о том, что техрадар не только картинка для руководства, но и ещё формат обсуждения технологий в организации и даже инструмент упрощения технологического стека.
И это действительно важное преимущество радара перед аналогами.

Мне всегда хотелось использовать что-то подобное для оценки инициатив (запросов на изменения). Чтоб сразу видеть истории, которые еще пару лет назад были отправлены в Hold (где им и место если не навсегда, то надолго). Понимать что уже в Adopt, и значит у кого-то в работе, а потому теперь не требует пристального внимания. Ну и сосредоточится на распределении тем между Assess и Trial

Техрадар дает карту возможностей. Но схожий инструмент для оценки потребностей был бы не менее полезен

Читаете ли вы заметки Kai Waehner о потоковой обработке данных? Я, признаться, почитываю. И хотя они порою даже длиннее, чем волны и хайпы(те же волны, но в другой проекции) Gartner-Forrester-а, читать их как-то поинтересней. В общем, свежее гадание: The Past, Present and Future of Stream Processing. На мой взгляд, слишком облачное для наших широт. (прочие истории этого автора здесь: https://kai-waehner.medium.com/)

🏛Архитектура решения (Solution Architecture), в некотором смысле, является наиболее простой архитектурой. Простой, если её, например, сравнивать с архитектурой предприятия или системной архитектурой. При разработке архитектуры решений мы достаточно хорошо понимаем целевое состояние, в которое должны прийти. Мы примерно представляем, когда это случится, каким в этот момент времени должен быть набор функций решения, как будут выглядеть данные, какой набор технологий мы задействуем. Более того, мы неплохо понимает текущий набор технологий, приложений и данных из которого мы будем это целевое состояние создавать.

Сравним для примера этот уровень определенности с тем, с чем мы работает при разработке архитектуры системы. Пусть нам предстоит спроектировать систему, про которую мы знаем, что через пару месяцев должен полететь MVP, через полгода заказчику хочется покрыть некоторый базовый функционал, а через год от текущего момента времени выйти на окупаемость. Какую архитектуру нам рисовать? Ту, что сложится через год, полгода или в ближайшие пару месяцев? Они будут очень разные. Первая пара месяцев, быть может, предсказуема с точки зрения технологий. За этот срок вряд ли что-то изменится. Но на начальный момент времени предметная область (domain) окутаны густым туманом. Может быть что-то можно сказать про компонентный состав, т.е. мы выберем тот самый то ли стиль, то ли паттерн из книжек Форда и Ричардса. Через пару месяцев мы слегка начнем понимать домен. Через полгода может быть уже разуверимся в предсказанный заказчиком профиль нагрузки и начнем менять тот самый архитектурный стиль. К горизонту год что-то будет меняться в технологиях под нашей системой. В ходе всей истории мы регулярно будем узнавать много нового о реальных навыках команды разработчиков, а быть может и выбранном техстеке.

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

Разве может InfoQ избежать соблазна прокатиться на очередной волне хайпа? Свой мартовский выпуск The Software Architects' Newsletter они посвятили, цитата:
This month, we focus on "Evolution of architectures: Monolith, microservices, and moduliths"

Исследование состояния DevOps в России 2024

Компания Экспресс 42 попросила меня выступить в качестве информационного партнера ежегодного масштабного исследования состояния DevOps 2024!

Если тема DevOps вам не безразлична – пройдите опрос и внесите свой вклад в развитие индустрии. Спасибо!

Alan McSweeney в своей книжке Introduction to Solution Architecture приводит целую палитру типов запросов к архитектору решений. И даже классифицирует их по уровню уникальности запроса, требуемой глубине проработки решения и ожидаемой продолжительности работы над запросом. Позволю себе пересказать описания этих типов так:

1. У меня есть отличная идея и я хочу поскорее увидеть варианты её реализации с ориентировочными сроками, стоимостью и требуемыми ресурсами.
Rapid Solution Design: Специфика высокая, сроки сжатые, уровень проработки небольшой

2. Мне нужен детально проработанный проект на основании требований или описания проблемы, которые не обязательно четко определены.
Традиционный Solution Design Process: Специфика низкая, глубина проработки высокая, сроки обычные

3. У меня особые требования к решению и мне нужна четкая спецификация для его разработки.
Detailed Design: Высокая уникальность, сроки ближе к среднему, детальная проработка решения

4. Я хочу увидеть варианты решения проблемы с высоты птичьего полета.
Early Engagement: Частый запрос, средняя продолжительность, уровень проработки неглубокий или средний

5. Мне нужна консультация для определения новых бизнес структур для решений, связанных с некоторой проблемой или возможностью.
Business Engagement: Конкретика запроса очень низкая, уровень проработки и длительность выше среднего

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

Однажды (шесть лет назад) я делился ссылкой на From Text to Models: A Comprehensive Guide to Textual Modeling and Diagrams as Code Tools За это время каталог уже не раз обновился, так что подниму вверх

Отчет InfoQ Software Architecture and Design Trends Report с каждым разом становится всё лаконичней.

Вышедшая в пятницу версия за 2024 год скорее представляет собой аннотированный набор ссылок на подборки InfoQ c новостями, подкастами и статьями. Причем прокомментированы только первые две колонки: инноваторы и ранние последователи. Преодолевшие пропасть подходы и технологии не обсуждаются. В общем, если что и можно отметить в отчете, так это появлении QR-кода на картинке

Похоже, чтоб разобраться придется слушать подкаст

Марк Ричардс выложил видео Running an Architecture Kata Session (очередной выпуск серии Software Architecture Monday). В нём он на второй минуте упомянул всеми нами любимого персонажа – джуниор архитектора, порекомендовал делать команды с нечетным числом участников и насоветовал ряд других более-менее очевидных вещей по структуре и таймингу проведения каты.

В том, что касается структуры я непременно соглашусь с форматом 10-минутного описания проблемы в начале каты и 5-минутной презентацией решения в конце. Но традиционно поспорю с архитектурными характеристиками и архитектурными стилями затесавшимися в середине. Ну, сколько можно популяризировать "звездную" табличку стилей-характеристик (я вот уже её постил однажды: https://tttttt.me/it_arch/1426)

Подкаст InfoQ Architecture and Design Trends in 2024 оказался содержательнее отчета. Не менее 20 минут уважаемые эксперты поговорили о трендах современных распределенных архитектуры. С их мнением можно соглашаться или не соглашаться (или вообще игнорировать), но хотя бы термины они прояснили

Сell-based architecture сразу утратила часть своего обаяния когда стало понятно, что речь идет о Bulkhead pattern. Причем этот термин представляется мне намного более понятным по сравнению с ячеистой архитектурой.

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

Рико Фриче порадовал текстом Domain-Driven Design: The Power of CQRS and Event Sourcing, в котором вместо традиционного уже пояснения что представляет собой CQRS/ES акцентируется на более глубоких аспектах. Прям целая россыпь идей, включая:

- замечание об однонаправленном поток данных(single direction flow) в отвечающих CQRS паттерну архитектурах. Я бы даже сказал, что речь идет о направлении потока изменения данных. Вот он един(но может разбиваться на рукава), упорядочен, с четко заданным направлением от одних элементов к другим. Чего обычно нельзя сказать просто о взаимодействиях;

- замечание, что объединение моделей чтения и записи данных приводит к более сильной связности (high coupling). Избавляясь от представлений для чтения, можно сделать модель записи более ориентированной на поведение. А независимость моделей чтения от записи открывает нам возможность построения набора независимых проекций данных

В общем, CQRS/ES не только про масштабирование

На сайте The Open Group появился небольшой обзор истории Archimate приуроченный к 15-летию выхода первой версии под эгидой TOG https://blog.opengroup.org/2024/04/18/celebrating-15-years-of-the-archimate-modeling-language-a-milestone-in-enterprise-architecture/