🗞 Журнал архитектурных решений
Запись моего выступления на конференции бизнес- и системных аналитиков, а немножко и архитекторов Flow2023 https://youtu.be/Qt26BQXSsvA&t=220

- c результатами июльского опроса: Чем ИТ-архитектор занят чаще всего внутри

Хотел написать недобрый комментарий про новый техрадар https://www.thoughtworks.com/radar Потому подумал, ну что я буду таких уважаемых людей журить. Ну, как вышло у них, так и вышло. Можем кому-то даже понравится

📚Меня регулярно журят за то, что часто я размещаю в канале ссылки без своих комментариев. И, в принципе, я согласен, что такой разбор текстов крайне полезен и занимателен. Но есть одна проблема. Если делать это сразу, то большинство может ограничиться прочтением комментария, а не исходного сообщения. Потому попробую провести небольшой эксперимент. Сегодня я размещу ссылку на текст, который три года назад довольно широко разошелся в сети. А после выходных поделюсь своим к нему отношением. Возможно, мы в чем разойдемся, а в чем0то и совпадем. Полезного чтения: 8 Tips to Better Architecture Diagrams

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

Потому я не стану цепляться к советам разместить данные сверху или непременно использовать draw.io (я его и так использую), а непосредственно перейду к 1,5 дельным замечаниям (один совет я засчитал за половину, т.к. большую его часть додумал самостоятельно).

Итак, первое, что меня зацепило – это картинка из второго совета, показывающая насколько убого строится диаграмма зависимостей в Visual Studio. Чтоб это стало понятно не нужно много слов. Достаточно просто рядом поместить картинку из ReSharper

Вторая полезная вещь частично навеяна тем же вторым советом, но в большей степени советом номер 3, да и другими советами тоже. И вещь эта в том, что в значительной доле случает ИТ-архитектору придется рисовать диаграммы, описывающие «физическую структуру» решения. Т.е. картинки, отвечающие на вопрос из чего состоит решение, основным элементом которых будут процессы (или системы или pod-ы или вызываемые методы… ). Рисунки из третьего столбца матрицы Захмана, если угодно. Или верхние буквы C из C4 model Саймона Брауна.

И какие бы мысли мы не хотели бы выразить своей диаграммой, воплощать их придется «поверх» вот этих самых контейнерных диаграмм. Поведение поверх стрелок, особенности организации данных поверх вообще всего (компонент, коннекторов и контейнеров). В общем, так или иначе пропитывать диаграмму необходимым нам смыслом. Делать то, что не предусмотрено нотациями моделирования.

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

Спасибо автору исходной заметки и как вам такой формат?

The Open Group решили порадовать нас мультиком про Archimate https://youtu.be/-7UhU4kGRUE?si=WzNlGLGs9IB_wDKW

📎 Давайте продолжим этот жанр. Напомню, что сначала я размещаю статью, а на этот раз серию статей Джеймса Хики What Are Domain-Driven Design Aggregates? а через пару дней напишу свой комментарий к этому тексту.

Возможно, наши суждения в чем-то совпадут, ну или дополнят друг друга. Итак, сегодня:

Агрегаты — одна из наиболее неправильно понимаемых концепций в предметно-ориентированном проектировании. Это просто скопление сущностей и объектов? Или что-то большее?

TOGAF Standard, 10th Edition Pocket Guide https://pubs.opengroup.org/pocket-guides/togaf-pocket-guide/main/introduction.html

That’s a lot of text to make 2 join tables
- это один из комментариев к исходному тексту. И с ним сложно поспорить. А вот с картинкой в финале этой заметки, на которой Member связывает два Bubbles, можно спорить до бесконечности. Ну, просто любая неоднозначная вещь способна вызвать подобный спор.

Но я не стану за это цепляться потому, что текст мне понравился. Мало кто из тех, кто пишет про DDD рассуждает об агрегатах. А я, как и автор статьи считаю, что это важно. Еще меньше доля среди DDD-писателей тех, кто отважится приводить простые (а значит всегда неоднозначные) примеры. Часто ИТ-авторам не хватает на это… искренности, готовности открыться для потенциального наезда от читателя. И в-третьих, мало кто из авторов простеньких примеров тут же поймает вас на рефлекторном желании «сделать быстро и неправильно». Словно психолог, покажет вам кляксы Роршаха и тут же обвинит вас в том, что вы увидели в них схему реляционной БД. Супер! Среди архитекторов широко известна концепция точки зрения (viewpoint). Но я бы сказал, что автор текста продемонстрировал нам другое. Назову это углом зрения или перспективой – способностью рассмотреть хорошо знакомые вещи некоторым новым способом

В общем, читаем продолжение DDD & Data Modelling: How Do I Persist Aggregates?

Вторая часть серии, на мой взгляд, оказалась заметно слабее первой. (Может тема такая). Тем не менее, я думаю, что оставшиеся две заметки:
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть

А слайды рассказа про Журнал архитектурных решений я так и не выложил. Исправляюсь!

В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide

🗿В прогрессе нет ничего неизбежного. Многие плохие идеи, которые были давно и надолго спрятаны, имеют тенденцию возвращаться

Это про монолит, если что. Длинный и довольно красочный текст, с большим количеством ссылок (я знаю, такие многим нравятся), возвращающий нас к неутихающему спору про монолит и микросервисы. Давно не было слышно сторону, голосующую за распределенные системы. Этот текст прерывает молчание. Честно говоря, мне понравилось. За 18 минут свободного блуждания мыслей автора я не встретил тезиса, с которым был бы готов поспорить. Наслаждайтесь! https://mikaelvesavuori.medium.com/on-complexity-and-monoliths-424ea76abaf5

Generated with DALL·E. Prompt: “a complex monolith in a server room, with the faces of IT consultants...

Mark Richards решил записать видео, в котором перечислил названия фаз TOGAF ADM. TOGAF 10 за 10 минут, так сказать.
Не очень понимаю зачем, ну да ладно https://youtu.be/AihWJ3_klRQ

Альберто Брандолини пробует пересмотреть метафору технического долга (не в первый раз, кстати; когда-то раньше он говорил о долге перед мафией). Заменить техдолг он предлагает целостным дизайном. Получается, на мой взгляд, не очень убедительно, но задуматься заставляет https://medium.com/@ziobrando/from-technical-debt-to-design-integrity-48e7056b6776

Как вам разноцветные цитаты в новой версии telegram? (это был просто вежливый вопрос, отчасти, как я надеюсь, замещающий утреннее приветствие)

А мы возвращаемся к жанру обсуждения околоархитектурных текстов. На этот раз я предлагаю вам вышедший на неделе текст Pierre Pureur и Kurt Bittner Has Your Architectural Decision Record Lost Its Purpose? и обещаю сделать его критический разбор через пару дней. (Я и правда довольно скептично настроен к тому, что пишут обычно эти авторы)

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

Но у меня сложилось впечатление, что Пьер и Курт часто делают примерно так. Сначала они пишут текст с рядом предложений и гипотез. Как, например, в вышедшей полтора года назад статье Software Architecture: It Might Not Be What You Think It Is. Потом они ссылаются на свою же статью, как на некий свершившийся факт, набор принятых, устоявшихся, само собой разумеющихся практик. (Что не всегда так). Так в старой статье предлагается отказаться от взгляда на архитектуру, как на структуру решения и полностью заменить описание архитектуры набором архитектурных решений. А потом, как бы сверху закрытой темы, нам советуют не путать архитектурные решения с другими решениями, важными, но не архитектурными. И архитектуры, в её традиционном виде, уже как бы давно не существует. А вот сейчас, на взгляд авторов, важно не замутить воду настоящих архитектурных решений решениями важными, но не архитектурными

Так и хочется крикнуть, словно вдогонку уносящему авторов поезду:
- Эй, ребята, Мы не с вами! Вы одни, сами с собой уноситесь на этом поезде в страну плюшевых единорогов.
Это у вас там пасутся стада Minimum Viable Architectures (MVA), эволюционирующие вместе со своими продуктами. Это у вас запрещены архитектурные описания в виде документов, а архитектурой занимаются абсолютно все потому, что профессиональные архитекторы давно уволены и т.д.

У нас же сохранились архитекторы и архитектурные описания. И ADRs дополняют их, а не отменяют. И смена языка, на котором пишется приложения, в 99,9% случаев является архитектурно-значимым решениями. И замена одной реляционной базы данных на другую – тоже архитектурное решение. (В тексте это примеры трудно заменяемых, но не архитектурных решений). Думаю, ключевая ошибка авторов в том, что они сводят всю пользу архитектуры исключительно к гарантиям атрибутов качества. Что абсолютно не верно!

В принципе, текст то довольно насыщенный, а порой и интересный. Но разбирать его надо критически, цепляясь буквально за каждую фразу. Вот, например, на мой взгляд нельзя просто так взять и написать:
Architecture, then, establishes limits on the kinds of problems a system can solve, and even, sometimes, on the ability of developers to see different kinds of solutions by establishing a kind of hammer-nail blindness to alternatives.
Ну, т.е. написать можно, но тут же должна набежать толпа архитекторов решений и объяснить авторам, что архитекторы для того и существуют, чтоб помочь увидеть альтернативные решения тем, у кого взгляд почему-то замылился. А еще напомнить, что выбор конкретной реализации всегда лишает нас преимуществ отвергнутых альтернатив. Так что ограничиваем мы не область проблем, а пространство решений. Не потенциально возможных решений, а решений, воплощенных на практике.

В общем, кто еще из нас muddies the waters, такие как я читатели, или же авторы текста – вопрос открытый!

А вот вам старая (8.1.1) зато кликабельная версия и TOGAF ADM. Выбирать можно кружочки на картинке с тогафовской ромашкой слева или закладки справа.

Наслаждайтесь http://www.togaf.com/admref/admreference.html