Продолжение: https://medium.com/@alexanderpolomodov/%D0%B2%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BE%D1%82-software-architecture-conference-2019-%D0%B2-%D0%B1%D0%B5%D1%80%D0%BB%D0%B8%D0%BD%D0%B5-part-ii-78425bba82d3

Только ленивый не похвалил очередную версию 3.1 нотации моделирования архитектуры предприятия Archimate за появление в ней потоков создания ценности, а я поругаю, но сначала краткое отступление. В позднем СССР было такое явление как педагоги-новаторы. В частности, Виктор Федорович Шаталов придумал метод опорных конспектов, по сути – хорошо проработанных шпаргалок, в котором выбору для понятий адекватных визуализации отводилось важное место.
В Archimate с пиктограммами всегда было не важно :( Возможно стрелочка и шеврон ассоциируются у кого-то с бизнес-процессом и бизнес-функцией, но у большинства людей они ассоциируются примерно с чем угодно. Но теперь, барабанная дробь, в стандарте появляется value stream. И какой же пиктограммой он отображается, как вы думаете?

Эта замечательная линейка была создана для рисования flowchart diagram. Представьте какого размера будет аналог для создания диаграмм в нотации Archimate 3.1 Поймите меня правильно. Мне нравится Archimate. Но ходить по встречам с таким огромным трафаретом не очень удобно

И снова про Archimate (не отпускает :). На этот раз цифра 3 - это количество измерений. Нас приглашают проникнуть внутрь трехмерной модели, выполненной в этой нотации: https://smarchy.com/blog/f/a-virtual-trip-inside-an-archimate-model

Спорим, что вы не знали о существовании такой спецификации? https://www.asyncapi.io/

В этом году у меня несколько раз просили порекомендовать архитектора экосистемы. Кто это такой? Какими компетенциями обладает архитектор экосистемы? Пока The Open Group безмолвствует на эту тему, появляются разные попытки создать, ну, например The Business Ecosystem Architecture Modeling (TEAM) framework. https://www.thevalueengineers.nl/what-is-your-ecosystem-the-ecosystem-architecture-modeling-framework/ По архитектурной традиции в фреймворке много букв "С": Company, Customers, Competitors, Complementors...

Интервью Gene Kim о книжке "Проект Единорог" (не путать с Фениксом). После The DevOps Handbook (2016) и Accelerate (2018) очередная вымышленная история, в которой рецензенты дружно узнают свои проекты. Буду ждать перевода https://www.infoq.com/articles/unicorn-project/

Какая прелестная новость пришла вчера про ГосОблако
(Государственная единая облачная платформа,
ГЕОП) Правительство назначило двух единственных исполнителей "Ростелеком" и НИИ "Восход" (не спрашивайте меня, как такое бывает) http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%93%D0%BE%D1%81%D0%BE%D0%B1%D0%BB%D0%B0%D0%BA%D0%BE_%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B5%D0%B4%D0%B8%D0%BD%D0%B0%D1%8F_%D0%BE%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0_(%D0%93%D0%95%D0%9E%D0%9F) В принципе, это всё что следует знать про ГосОблако хотя ниже и написано многабукв

Прикольный титл у презентации: Камо грядеши (Куда ты идешь), Enterprise Architecture Management?

Предсказываю паттерны корпоративной интеграции. Недорого! Гарантированный результат!

O'Reilly купил https://www.katacoda.com/ Демо, которые я использовал в курсе Микросервисная архитектура, https://itexpert.ru/msa/ остаются в открытом доступе (пока?). Что будет с новыми интерактивными обучающими сценариями не очень понятно. Подробности здесь: https://www.oreilly.com/online-learning/interactive-learning.html

Познавательно о governance https://twitter.com/DPBoK_TM/status/1197215095069331459

При всём огромном уважении к Мэтту Стайну (автору знаменитой книжки "Migrating to Cloud-Native Application Architectures" и других отличных текстов) его перечисление стратегий декомпозиции мне представляется неполным https://builttoadapt.io/whats-your-decomposition-strategy-e19b8e72ac8f Впрочем, вопрос затронут мега-важный. Наверное, самый важный для архитектора ИТ-решений

Сейчас будет очередная серия заметок в формате «много слов об одном и том же». На этот раз о том, почему техника Domain Storytelling (далее DS) сорвав низко висящее яблоко, не съела его, а всего лишь понадкусывала.

Вообще, проводить анализ-дизайн в виде веселых групповых сессий с рисованием каракуль и развешиванием стикеров хорошо и правильно. Неправильно выходить с таких сессий без внятного результата. В DS совершенно справедливо полагается, что создать хорошую модель предметной области в DDD-подходе невозможно без обсуждения поведения. Именно это помогает нам определить агрегаты, репозитории, быть может даже ограниченные контексты. В общем, те сущности, которыми мы оперируем в domain driven design. Проблема DS в том, что всех этих агрегатов, объектов-значений и пр. в нём нет. Персоны есть, документы есть, даже e-mail и смартфоны есть, а вот агрегатов нет. Зачем же мы тогда проводим такие сессии? #карта_предметной_области

Изначально в DDD было принято рисовать концептуальные карты (concept map). Это отличный метод, у которого есть всего лишь два недостатка. Первый заключается в том, что нарисовать при помощи концептуальной карты можно примерно всё. Т.е. метод настолько универсален, что мало отличается от набросков на салфетке и поэтому и методом то может называться с большой натяжкой. Проблема номер два: концептуальная карта – это граф. Рисовать его более-менее просто, а вот читать нет. Нету в нем сжатия информации и потому эффекта мгновенного понимания ожидать от такой картинки не следует. Ну и вспоминая основную находку Domain Storytelling – совмещение описания структуры и описания поведения, мы вынуждены признать, что в концептуальных картах DDD этого тоже нет. В общем, максимум для чего они годятся – выделять границы контекстов
#карта_предметной_области

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

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

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

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

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