Развилки архитектурных решений
Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку [читать дальше...]

Нашел вот такое исследование Difficulty of Architectural Decisions – A Survey with Professional Architects, в котором поучаствовало 43 архитектора и 86 архитектурных решений.

См. основные затруднения на картинке выше. В исследовании так же пытаются найти различия между решениями начинающих и опытных архитекторов, а еще: decisions with a more preferable outcome (i.e. good decisions) and decisions with a less preferable outcome (i.e. bad decisions)

Читаю TOGAF® Series Guide - Architecture Skills Framework и рассматриваю таблички с навыками разных архитекторов. Вот интересно, а кто всё это придумывает! Из каких вот соображений? Почему, например, у Solution Architect знания языков программирования должны быть выше, чем у архитекторов приложения и технических архитекторов, а готовые решения (COTS) ему надо знать в меньшем объеме (табличка из раздела 5.5 IT General Knowledge Skills)? И насколько все это согласуется, к примеру, с тем же SFIA Solution architecture?

Еще один пример Event Storming, Black Magic or Real?

14 сентября в 10:30 расскажу про свой новый учебный курс
Модели корпоративной архитектуры.
TOGAF 10 и Archimate 3.2

📎 Подробности и регистрация

Думаю, этот джин лениво выползает из своей бутылки. Сначала McKinsey утверждает, что Yes, you can measure software developer productivity. Потом Kent Beck начинает с ними спорить (см. часть 1, часть2), рассказывая как продавцы и рекрутеры обманывают свои KPIs и чем их труд отличается от разработки. В конечном счете все вокруг теперь обсуждают как измерять программистов

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

В общем, мир, в котором все программисты работают на 3-5 облачных PaaS за скромное вознаграждение, уже не выглядит такой уж абсолютной утопией

Добавил ответы на часть вопросов, касающихся Solution vs. Enterprise архитектуры https://youtu.be/cNRyS3qQXBc

Текст, конечно, старый, но всё еще актуальный https://medium.com/iasa-global/why-frameworks-are-killing-architecture-ebd758b5137e

https://tttttt.me/it_arch?boost

Проголосуйте за наш канал (для обладателей premium подписки. Если ссылка еще не видна, то она появится после обновления приложения)

🗞 Журнал архитектурных решений
Запись моего выступления на конференции бизнес- и системных аналитиков, а немножко и архитекторов 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?