Смотрите какую замечательную вещь предложил Vladimir Khorikov: https://enterprisecraftsmanship.com/posts/types-of-cqrs/ Сделать CQRS "измеряемой" характеристикой: нет CQRS-а, немного CQRS, чуть больше CQRS и т.д. Практически, как REST maturity model от Leonard Richardson. CQRS в нашем решении увеличивается когда: появляются отдельные методы, например для поиска; разделяются классы для работы с данными и их сохранения, выделяются разные модели для чтения и записи, чтение выделяется в отдельный(ые) сервисы, разделяются системы хранения данных для чтения и записи.

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

- Мастерская проектирования ИТ--решений
- Микросервисная архитектура
- Практики архитектуры предприятия

🙋Ваши вопросы по учебным курсам вы можете задать в комментариях к этому сообщению

Brian Foote and Joseph Yoder
Big Ball of Mud

Shantytowns emerge where there is a need for housing, a surplus of unskilled labor, and a dearth of capital investment. Shantytowns fulfill an immediate, local need for housing by bringing available resources to bear on the problem.

All too many of our software systems are, architecturally, little more than shantytowns... Deadlines loom like monsoons, and architectural elegance seems unattainable

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

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

Есть такой жанр у авторов текстов по ИТ-архитектуре – многабукв, абстрактные рассуждения и без картинок. Бен Моррис, вполне относится к представителям этого жанра (картинка в сообщении от меня). Но есть в его заметках и некоторое отличие. Во-первых, в них практически всегда присутствует TL;DR, а еще, обычно, написаны довольно правильные вещи. Как, например, в тексте Когда событие не является событием, (... а является сообщением, запросом, командой, сущностью и т.д.)

Наш канал является одним из информационных партнеров
Ежегодного масштабного исследования состояния DevOps в России 2023, которое проводит компания Экспресс 42 совместно с Yandex Cloud, Head Hunter, OTUS Онлайн-образование и Флант!

Если тема DevOps вам не безразлична – пройдите опрос https://e42.link/state-of-devops23 и внесите свой вклад в развитие отрасли.

Важно мнение каждого!

Для всех, кто заполнит опросник, коллеги из Экспресс 42 приготовили подарки.

Участники опроса станут самыми первыми, кто узнает о результатах и получит отчет, как только он будет готов!

Заполнить анкету можно по ссылке➡️ https://e42.link/state-of-devops23

Международный институт бизнес-анализа IIBA в ноябре прошлого года выпустил новую книжку The Business Analysis Standard Можно считать, что это еще один упрощенный и переформатированный пересказ BABOK Guide, но:
- сделан он довольно неплохо
- получить его можно совершенно бесплатно (на сайте IIBA, за регистрацию https://go.iiba.org/The-Standard)

В самом начале года я уже писал, что обсуждать в 2023 мы будем платформы. Так оно и происходит. Даже невнятная статья Сэма Ньюмана Don't Call It A Platform, про "обитаемость", прошла по всем архитектурным рассылкам.

Никто не любит ограничений! А платформы их, безусловно, накладывают. Но, похоже, нужны они или нет обсуждать уже поздно. А пора договариваться о границах и функциях платформ

Основы архитектуры ПО. Глава 9 Архитектурные паттерны / Максим Смирнов

Получилось интересно, Максим говорит правильные вещи простым языком. Поговорили про антипаттерн Big Bаll of Mud, Максим рассказал как распознать на собеседовании что с архитектурой, что то не так. Обсудили вопрос различий монолита и микросервисов, пришли к выводу что сейчас приложения уже гибридные. Так же поговорили про каждое из trade off (не устойчивость сети, задержки, безопасность, пропускную способность) связанных с микросервисной архитектой. 

Смотреть YouTube, Boosty ❤️
Cлушать Apple Podcast, Yandex Music 🎧

А тем временем Mark Richards в своих архитектурных понедельниках рассказал нам про матрицу Захмана https://youtu.be/IaQddw-uCvY

Вернее о том, во что она превратилась в конечном счете. Вы можете почитать оригинальную статью Extending and formalizing the framework for information systems architecture 1992 года с сайта Захмана, чтоб убедиться, что матрица там не совсем такая и Марк комментирует более позднюю версию.

Ну, а для самых дотошных вот эта статья The Zachman Framework Evolution by John P Zachman с историей переписывания содержания клеточек, названий строк и столбцов

ЗЫ: Моё старое обещание о новой серии разговоров про матрицу Захмана остается в силе :) Не отписывайтесь от нашего канала!

Наш канал является информационным партнером онлайн-дискуссии КРОК Облачные сервисы с Александром Баталовым, генеральным директором компании «Флант»

Kubernetes на российском рынке

23 марта в 16:00, приглашаем вас присоединиться и обсудить:
• Тренды российского рынка Kubernetes. Почему растет востребованность технологии k8s?
• Kubernetes сегодня и три года назад — как изменился запрос?
• Перспективы платформы: как будет развиваться технология и как ее будет использовать средний и крупный российский бизнес?
• Сложности внедрения Kubernetes и как с ними справляться
• Путь Флант: от сервисной компании к вендору платформы оркестрации контейнеров

🧑‍💻 Ведущие:
Сергей Зинкевич, директор по развитию бизнеса КРОК Облачные сервисы

Александр Фикс, менеджер по развитию бизнеса КРОК Облачные сервисы

📌 Регистрируйтесь здесь

Если у вас есть вопросы по теме Kubernetes, оставляйте их в комментарии к этому посту. Мы постараемся озвучить и ответить на них в прямом эфире

Узнал я новое слово на букву "С". На днях Билгин Ибрям написал довольно большой текст на InfoQ What Are Cloud-Bound Applications? о том, что же привязывает наши приложения к конкретным инфраструктурам, платформам и сервисам

В Scaled Agile Framework есть ряд идей, на которые я часто ссылаюсь в своих курсах, вебинарах и выступлениях. Например, выделение трех основных архитектурных ролей (enterprise, solution и system architect) или воронка Portfolio Kanban, позволяющая определять приоритеты задач на основании рассмотрения альтернативных вариантов реализации(см. рисунок).

Это совершенно не значит, что я за SAFe или же против него. Чтоб избежать предвзятого отношения я позволю себе поделиться ссылкой на сайт The SAFe Delusion оставив каждому подписчику труд выработать то или иное собственное отношение к SAFe или возможность не делать этого вовсе

Simon Brown добавил несколько примеров альтернативных визуализаций в https://c4model.com/#AlternativeVisualisations

Выше я ссылался на его выступление Diagrams as Code 2.0 с идеей, что модель не только первична по отношению к диаграммам, но и может быть выражена разными нотациями моделирования

Текущие результаты опроса (Google Tree Map Chart)

Ежегодно O'Reilly анализирует поисковые запросы по своим книжкам и курсам и пишет об этом большой и бестолковый отчет Technology Trends for 2023. В этом году он появился 1 марта, но у меня все не доходили руки с ним разобраться.

Честно говоря, чтения отчета несколько меня разочаровало. Я бы предпочел набор сырых данных (меньше букв, больше цифр). По крайней мере, тренды по архитектурным словам (см. график) я понять не сумел. Согласно отчету растет всё:

- Архитектура ПО выросла в 2022 по сравнению с 2021 годом на 26%.

Видимо, это в абсолютных величинах, но нигде не написано насколько выросло общее количество запросов. В общем, после таких данных хочется задать вопрос: ну и что?

Я остановил опрос с такими текущими результатами:

В нашем чате более 500 архитекторов решений (Solution Architect), более 330 системных и 150 бизнес-аналитиков. Более 300 разработчиков. А еще 250 архитекторов ПО и примерно столько же человек, которые позиционируют себя в качестве Enterprise Architect. Меньше системных инженеров и QA

Я пропустил тот момент, когда ассоциация всех ИТ-архитекторов IASA вместо руководства по архитектуре ITABOK стало развивать The Business Technology Architecture Body of Knowledge (Btabok) Кто-нибудь разбирался с этим?

Вышла стенограмма InfoQ Software Architecture & Design Trends 2023

Честно говоря, я не подписан на Криса Ричардсона и потому заметку About dark energy and dark matter: forces that shape an architecture, появившуюся в его блоге в прошлые выходные, увидел сейчас впервые (хотя метафору эту он использует уже давно).

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