Описание на одной картинке структуры и поведения – сложная задача. В 60-70 годы прошлого века в картографии случилась своя технологическая революция – появление геоинформационных систем (ГИС). Собираемые для отображения на карте данные перестали сразу же наносить на бумагу, а стали складывать в структурированные хранилища. Затем программа вбирала из такого хранилища нужные для визуализации на данной конкретной карте вещи, отображаемые слои и т.п. и формировала изображение. По аналогии с картографией в ИТ-архитектуре появилась идея единого репозитория из которого формируются нужные для решения данного класса задач и понятные для некоторой группы заинтересованных лиц представления (view). Но проблема ИТ-архитектуры в том, что никто толком не научился совмещать на одной картинке разные слои. Рисовать в одном представлении, например, и структуру и поведение.
#карта_предметной_области

Что-то никто не отписывается, тогда продолжу. Вернемся к DDD и поговорим об описании агрегатов [1]. Агрегат – это кластер нескольких объектов предметной области, рассматриваемых как единое целое. Эффектный, но не особо эффективный способ отображения таких кластеров – представление их в виде молекулы. В центре корень агрегата (aggregate root), к которому крепятся сущности и объекты значения. В таком формате представления отсутствует ряд важных моментов. Во-первых, часть ветвей являются взаимоисключающими. Например, в агрегате заказ вы либо забираете его в пункте самовывоза, либо просите доставить курьером на дом, но никак не одновременно. Другие элементы заказа, такие как набор покупок, взаимоисключающими не являются. Более того, агрегат — это не вполне дерево. Разные ветки могут быть связаны довольно сложными зависимостями
#карта_предметной_области
[1] Картинка взята из статьи Domain-Driven Design in an Evolving Architecture

Чем заменить концептуальную карту (молекулу) при моделировании DDD агрегата? За ответом ходить далеко не надо. Достаточно заглянуть в статью Википедии Представление знаний. Сразу же после семантической сети, а это была именно она, следует раздел Фреймы. Фреймы для представления знаний любимы не только в экспертных системах, но и в среде архитекторов. Наверняка вам доводилось видеть картинки-этажерки или холодильники, в которых по полкам (слотам) по определенным правилам размещаются те или иные вещи (бутылки на полку, пельмени – в морозильник). Вот это и есть фреймы. Значительная часть агрегатов неплохо моделируется фреймами. Вспомните заказ из предыдущего примера
#карта_предметной_области

Удивительно то что, когда нужно пояснить что такое агрегат на пальцах, даже такие великие эксперты как Мартин Фаулер рисуют именно холодильник(фрейм) https://martinfowler.com/bliki/AggregateOrientedDatabase.html Однако, коль речь заходит о серьезной статье, место понятных картинок занимают UML диаграммы классов и фрагменты кода. Правилом хорошего тона считается включать именно фрагменты кода, даже если в них нет какой-либо логики и просто приведены названия методов и структура данных
Кстати, стрелки на этой картинке направленны не в ту сторону. Скорее всего они олицетворяют ссылки на таблицы, но для совмещения описания поведения со структурой нам понадобиться другая логика в направлении стрелок
#карта_предметной_области

В представлении знаний фреймами нет ничего необычного. Скорее наоборот. Мы настолько часто с этим встречаемся, что просто не замечаем этого. Так что еще пара примеров. Бланк заявления (форма), включающий несколько разделов, заполняемых разными людьми. Какие-то разделы такого бланка обязательны. Необходимость заполнения других зависит от предыдущих разделов. Kanban-доска, по которой путешествуют стикеры работ. Бизнес-процесс, представленной сетью Петри …, впрочем, это мы уже спешим и переходим к отображению поведения
#карта_предметной_области

Пора переходить к поведению. Что это такое? Из чего оно состоит? Можно довольствоваться утверждением, что поведение – это последовательность событий, запросов и команд (events, queries, commands) и дальше разбирать каждое из них, но слово последовательность я бы заменил на параллельность если бы такое существовало. Последовательностью это было во времена появления клиент-серверных архитектур. Всё моделирование поведения, к сожалению, предполагает контекст, когда пользователь утром включает алфавитно-цифровой терминал, устанавливает соединение с сервером и отправляет ему команды в синхронном режиме. Сегодня даже в бизнес-процессах – очень поверхностном подходе к описанию поведения, принято смещать акцент с оркестровок на хореографии. А информационные системы, с десятками одновременно исполняемых, а часто и взаимодействующих друг с другом, процессов только на одном узле – это уж точно не про оркестровки. Тем не менее, давай чуть подробней поговорим о событиях, запросах и командах…
#карта_предметной_области

Осталось совсем немного. Всего пара реплик. Сначала о структуре активности. Есть много источников, чтоб подсмотреть какие объекты может объединять операция. Я взял вот отсюда: https://www.w3.org/TR/activitystreams-vocabulary/

actor | object | target | result | origin | instrument

вы можете воспользоваться другими источниками. Главное – понимание того, что операция является N-мерной ассоциаций, собирающей множество разных объектов. Помимо глагола это: инициирующий операцию actor и object, с которым операция производится. Target и origin – куда и откуда перемещается actor-ом наш object, Помните, агрегат - это шкаф с набором полок; при помощи чего эта операция производится (название API или экранной формы, в общем объект boundary из robustness diagram)
#карта_предметной_области

Вспоминая картинку Фаулера, мы скорее нарисовали бы эту историю так: авторизованный пользователь при помощи формы выбора способа оплаты выбирает для данного заказа один из использованных ранее платежных инструментов. С точки зрения DDD в заказе создается объект-значение (value object). Он не будет меняться, даже если в дальнейшем мы отредактируем или удалим этот способ оплаты в клиентском профиле.
#карта_предметной_области

ИТ-архитектор! Приоткрой рекрутерам правду, поучаствуй в опросе:

Перевод гартнеровского хайп-цикла 2019 https://habr.com/ru/company/samsung/blog/477040/ Если быстро пролистать все эти контуры надвигающегося будущего, то можно найти не только русскоязычную картинку, но и упоминаниятаких слов, как DigitalOps и Knowledge Graphs

Более двухсот ИТ-архитекторов проголосовало в опросе. Понятно, что опрос в telegram это не исследование, а скорее повод для размышления, но всё же:

Количество архитекторов, которые нигде не работаю и ищут работу – минимально (чуть больше 1%). Интересно было бы обсудить насколько долго архитекторы не работают, но боюсь, что эта величина будет в районе weekend-а; максимум краткосрочного отпуска.

А вот удовлетворенных текущей работой архитекторов меньше половины. 52% работают где-либо, но открыты для новых предложений. Понятно, что этот показатель может быть завышен, т.к. опрос изначально был задан в группе «Работа для ИТ-архитекторов». Но, как мы это уже успели обсудить в чате, похоже, что проблема не в том, чтоб ИТ-архитектора найти, а в том, чтоб удержать и развивать. Кстати, готов обсудить эту тему предметно

Очень немного людей представляют собой так называемых пассивных кандидатов (так что современный интерес к сорсингу, похоже, не про архитекторов) 12% отметили, что неспешно ищут работу. Еще 18% верят, что работа мечты, в принципе, существует. Вместе с категорией ИТ-архитекторов, которые не готовы менять работу (17%) – это составляет четверть участников опроса

До меня дошло(как до жирафа) что за список недавно форбс выпустил. На сайте суперджоб сотрудники ставят оценки своим работодателям https://o.superjob.ru/ а те, если захотят, разрешают публикацию статистики по таким оценкам

Опрос еще продолжается. После 277 участников результаты выглядят так

Архитектор решений (solution architect) глазами сервиса CareerExplorer https://www.careerexplorer.com/careers/solution-architect/ Откуда берется, что делает, сколько получает, насколько доволен жизнью...

Любопытная картинка в продолжение разговора про архитектора решений https://dalbanger.wordpress.com/2017/05/07/the-solution-architecture-life-cycle/

Чем мне всегда нравились solution architect-ы, так это умением избегать оценочных суждений, категорий хорошо и плохо. Вот взять вчерашнюю картинку. Солюшн не будет её критиковать или хвалить, а скорее скажет, что она лучше или хуже отражает реальность, чем например вот такая: https://scalingsoftwareagility.files.wordpress.com/2010/03/screen-shot-2010-03-05-at-3-13-01-pm.png Проф.деформация своего рода: следствие многолетнего сравнения различных альтернатив

На этой неделе книжка появилась в продаже. А на сайте IT Revolution за регистрацию раздают первые 7 глав (более сотни страниц) https://itrevolution.com/the-unicorn-project/

UPD: Кстати, ничего себе так. История захватывает

Редкое видео от мэтра Philippe Kruchten - What Colours is Your Backlog? (2013) https://youtu.be/PhhUYi37rIo

Предновогодний марафон. В канун Нового года многие сообщества подводят итоги. Хочу предложить участникам группы Архитектура ИТ-решений сделать тоже самое, ответив на четыре вопроса:
1. Как вас зовут и чем вы сейчас занимаетесь
2. Что, на ваш взгляд, произошло важного в ИТ-архитектуре в 2019 (в стране, мире, вашей компании или системе)
3. Какие события, книги, выступления запомнились в 2019-м
4. Что нам ждать в архитектуре ИТ-решений в 2020-м

Ответы я буду публиковать (вероятно, порциями) в канале Архитектура ИС и дублировать в группу Архитектура ИТ-решений