Пожалуй, это самая важная картинка в недописанной книжке Брандолини Introducing EventStorming Правда, она скорее объясняет, что такое CQRS, а не рассказывает про Event Storming или Domain Driven Design. Тем не менее, идея инициируемой командой пользователя петли событий, возвращающейся к нему же или порождающую новую команду – это базовый сценарий взаимодействия пользователя с сервисом. Всё крутится вокруг этого…

… даже процесс DDD или предметно-ориентированного проектирования. Сравните картинку из реплики выше c рассказом Брандолини о The Whirlpool Model https://blog.avanscoperta.it/2020/08/03/which-process-for-domain-driven-design/ Эрика Эванса

Простое пошаговое описание Event Storming с сайта про архитектуру от IBM https://www.ibm.com/cloud/architecture/architecture/practices/event-storming-methodology-architecture/ Ничего лишнего.

Автор С4model Саймон Браун не только написал «Missing Chapter» в книжку Роберта Мартина «Чистая архитектура». Здесь The delivery mechanism is an annoying detail и здесь Clean Architecture вы можете почитать дискуссию этих уважаемых экспертов случившуюся еще в 2011.

Но я бы развернул это обсуждение в противоположную сторону. Меня тоже всегда интересовал вопрос почему дядюшка Боб 1) решил, что бизнес-сущности и сценарии (entities, use cases) меняются наиболее редко и потому нуждаются в избавлении от зависимостей в первую очередь 2) кто расскажет об этом бизнес/системным аналитикам, которые обычно и отвечают за выделение в предметной области сущностей и юзкейсов. Если мы в это верим, то влияние аналитиков на дизайн ИТ-решения становится колоссальным. (Но вряд ли они об этом даже подозревают).

Не понимаю я современного работодателя! На hh в московском регионе 16(!) архитектурных вакансий включают слово Zachman (и еще 4 – Захман). Зачем это современному корпоративному архитектору? Я в своих курсах рассказываю про матрицу Захмана, но не как о рабочем инструменте, а скорее в формате некоторой ретроспективы развития EA. Но работодателю то это зачем? Я понимаю, когда требуют TOGAF (75 вакансий) или Archimate (78). Но зачем требовать подходы, сформулированные Джоном Захманом еще в 1987(и скорректированные в 1992), я понимаю не очень

7 июня 19:00 MSK
Предыдущее сообщение за пару часов набрало 30 комментариев. Предлагаю продолжить обсуждение затронутой темы голосом сегодня вечером. Прямо здесь. Присоединяйтесь!

PS: Вопросы можно добавлять в комментариях к этому сообщению 👇

Анонсированные в вчерашнем чате "9 принцев Амбера" от Евгения Чикунова

Текущие результаты опроса (1318 голосов) за вычетом варианта Посмотреть результат:
52% - Solution
24% - Enterprise
22% - System
16% - Application
8% - Infrastructure

Почему-то я пропустил этот опрос O'Reilly Microservices Adoption in 2020 (Everyone’s talking about microservices. Who’s actually doing it?). Может раньше он не был в открытом доступе, не знаю.

Конечно, отчет не очень свежий(начало 2020), но довольно интересный. С попытками обнаружить и прокомментировать корреляции между ответами на разные вопросы. Т.е. с тем, что отличает подготовленные исследования от традиционных тупых опросников. В общем, всё как мы любим

📆 20 июня 19:00 MSK Архитектор ИТ-решений. Несколько полезных приемов - бесплатный вебинар с обсуждением навыков архитекторов решений (Solution Architect)

Зарегистрироваться на вебинар, задать вопросы, поделиться собственным опытом можно по ссылке: https://mxsmirnov.timepad.ru/event/2071039/

Присоединяйтесь!

А запись выступления Саймона Брауна Diagrams as Code 2.0 на GOTO Copenhagen 2021 выложили только позавчера. Интересующимся: https://youtu.be/Za1-v4Zkq5E

Страничка про компетенции от IASA - An Association for All IT Architects https://itabok.iasaglobal.org/itabok3_0-2/people-model/competency/

Наивно рассчитывая победить спам, я временно отвязал от канала группу для обсуждения опубликованных здесь материалов. Те, кто был в группе, могут беспрепятственно продолжать в ней общаться. Напоминаю и про другие наши группы:
- ИТ-архитектура во всех её проявлениях https://tttttt.me/itarchitect
- Работа для ИТ-архитекторов https://tttttt.me/itarchitect_jobs

Я не помню кто именно притащил в ИТ-архитектуру концепцию Shearing layers из книжки Стюарда Бранда How Buildings Learn: What Happens After They’re Built, но идея "хорошей архитектуры" в этом подходе вполне очевидна: слой с частыми изменениями должен оказаться выше слоя с изменениями более редкими.

Похожая идея применима и для профессий и навыков. Пока рынок труда хорош мы добавляем к своей базовой профессии слои с новыми компетенциями и специализациями. Когда рынок сжимается - возвращаемся к базовой профессии: разработчика, инженера, аналитика или менеджера