Вот эта канва описания ограниченных контекстов в предметно ориентированном-проектировании (DDD bounded context) https://medium.com/nick-tune-tech-strategy-blog/bounded-context-canvas-v2-simplifications-and-additions-229ed35f825f чем-то похожа на шаблон описания микросервисов (см. выше https://tttttt.me/it_arch/179) не так ли?

Вот оно оказывается как! После перехода от проектной организации работ к продуктовой, вдруг оказывается, что нужны программы. Новая статья на martinfowler.com: https://martinfowler.com/articles/programs-in-product-mode.html

Довольно неоднозначная, но полезная история https://www.codeproject.com/Articles/4043134/Message-Driven-Business-Process-Orchestration-usin Неоднозначная потому, что я бы повыкидывал бы половину БД на картинках (например на Figure 4. одна из стрелок точно лишняя, ну да ладно). Почему интересная: системы управления бизнес-процессами явный тормоз развития микросервисов: транзакции, состояния и т.п. О таких темах, как S-BPM, вроде бы, все уже давно забыли. Zeebe - чем-то принципиально новым не считаем, она о другом.

Но в тоже время в современных нам ИТ-архитектурах появилось столько всяких новых вещей. Например, а не пора ли включать в BPMN пиктограмму circuit breaker? Ну и вообще, что может быть более похожим на паттерн event sourcing, чем позиции из сетей Карла Петри. Сети Петри, вроде как для моделирования процессов придумали, разве нет?

В общем, митап пора делать о бизнес-процессах и микросервисах

Подарок архитектору предприятия от YouExec Бесплатный шаблон для Google slides или PowerPoint (и не говорите, уважаемые EA, что вы его не используете) из семи анимированных слайдов презентации бигбоссам стратегических карт https://youexec.com/strategy-maps-3e2djzvibo

Может быть нарочито просто, зато доступно про онтологии и графы знаний, с картинками и примерами: https://enterprise-knowledge.com/whats-the-difference-between-an-ontology-and-a-knowledge-graph/

Завтра в 10:30 MSK приглашен на запись очередного подкаста linkmeup Весь выпуск будет целиком посвящен ИТ-архитектуре https://linkmeup.ru/blog/528.html Слушать можно непосредственно в ходе записи или скачать позже. На то это и подкаст ;-)

А тем временем на Хабре появилось несколько переводов про REST. Первый: "REST API должен основываться на гипертексте" https://habr.com/ru/post/483528/ одного из сообщений Роя Филдинга в его блоге и нескольких комментариев к нему (Оригинал 2008 года: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

И еще один перевод https://habr.com/ru/post/483328/ вызвавший больше флейма, чем понимания

Если вы регистрировались на сегодняшний вебинар, но не получили ссылку на трансляцию, то вот она: https://youtu.be/tky1EiWRpNE

Начинаем в 11:00

Слайды сегодняшнего вебинара

Про вовлеченность аналитиков и архитекторов

Задачка по архитектуре предприятия (вымышленная): есть несколько систем, поддерживающих одну функцию. Например, CRM от мегавендора, развиваемый интегратором, самописный внутрикорпоративный сайт с данными о контактах с клиентами (интеракциях) и база знаний на готовом движке, развиваемая собственными силами. В компании идет рационализация портфеля приложений. Как правильно поступить: объединить три системы в одну, оставить как есть, объединить сайт с CRM, слить сайт и базу знаний, заменить всё новой коробкой.

Вопросы и уточнения в группе канала. Голосование ниже

Несколько моих соображений по кейсу:
1. Безусловно, всё определяется контекстом и нет каких-то общих рекомендаций по объединению/разделению приложений
2. Более того, будущее важнее настоящего (ну, если у нас ничего не рушится в текущий момент и не надо срочно тушить пожары). Т.е. куда мы пойдем зависит от ожиданий через год-полтора-два или десять.
3. Если сегодня цели противоречивы: служба работы с клиентами ожидает быстрых дешевых изменений, на которые не способен интегратор с текущей CRM коробкой; ИТ нацелено на контроль над complexity, в идеале не больше одной системы на бизнес-функцию и т.д., то это не значит, что так будет всегда. Т.е. надо садиться за стол, рисовать картинки и договариваться о будущем, пусть не очень близком, но обязательно светлом.
4. Но сначала глобальные тренды. Поддержка будет уходить в digital-каналы, людей заменять искусственные интеллекты, базу знаний вести и читать станут сами клиенты, нерадивых системных интеграторов постигнет agile, а часть их работы будут делать citizen developers со стороны заказчика. Да и вместо CRM-ов e у нас будут coreless, облачные customer experience платформы на микросервисах. Ответы на вопрос "когда?" – к вендору, интегратору и своим разработчикам
5. Но это всё случится не скоро, поэтому на пути к светлому будущему надо предложить среднесрочные варианты, позволяющие снять часть текущих противоречий. (Противоречивость требований – причина декомпозиции систем на части; верно и обратное - устранение противоречий упрощает ИТ-ландшафт)
6. Не все предложенные варианты взаимоисключающие. Можно рисовать этапы. Перед наступлением единой микросервисной (кто сказал микросервисной? Я не говорил) платформы будут промежуточные этапы. Например, отсутствующее в вариантах объединение самописного сайта и базы знаний или доработка текущего CRM силами внутренней команды и т.п. Так что обсуждение стратегического целевого состояния, с которым все согласны, мы заменяем на тактику прокладывания маршрута
7. Если мы не договорились по тактике, то как минимум надо договориться обвести одним кружком все системы (не люблю слово «платформа», но видимо назвать это надо так) и координировать все работы в рамках этой области

Большое спасибо всем откликнувшимся! Вопросы и комментарии приветствуются в группе канала

Скажите мне, что я сплю, и на самом деле Wardley Maps не имеют абсолютно никакого отношения к микросервисной архитектуре, т.е. соотносятся с технологиями примерно так же, как придуманные древними созвездия с реальным расположением звезд и мне не придется смотреть и анализировать вот это видео https://youtu.be/1cnLMuBABo0

Вот сейчас я проснусь и всё встанет на свои места. А звезды будут лишь точками на небе и между ними не будет никаких линий, как в планетарии

Domain Driven Design рекомендован многими авторами в качестве подхода распределения данных между [микро]сервисами. Но мне всё чаще приходится сталкиваться и с другими способами декомпозиции. Как говорится, не DDD единым разбивается монолит на микросервисы. В какой-то момент я начал коллекционировать такие способы. Ну, например, вы можете сделать декомпозицию, которую я называю шардирование по состоянию, храня в различных базах данных информацию об экземплярах бизнес-процессов, достигших некоторого состояния (на самом деле, удобнее хранить в одной базе экземпляры процесса, которые находятся "в шаге" от некоторого состояния; такая база размещается в перехватчике событий, переводящих процесс в это состояние) Много интересных идей можно найти, в ходе чтения книжки https://www.piter.com/product/raspredelennye-sistemy-patterny-proektirovaniya рекомендовал её и здесь в своем блоге https://mxsmirnov.com/2019/09/28/designing-distributed-systems/

А есть ли у вас примеры подобных паттернов (или антипаттернов)? Поделитесь, пожалуйста, в группе обсуждения этого канала

Kubernetes Failure Stories https://k8s.af/

Второй день в чатике архитекторов https://tttttt.me/itarchitect продолжается обсуждение очередной серебряной пули (кстати, открыл для себя несколько новых слов, например "АСУнизация")

Всё же не зря буржуи развивают культуру питчинга (... и здесь я должен бы в очередной раз порекламировать свой тренинг по архитектуре ИТ-решений, но воздержусь :)

… я сейчас глупость одну скажу в продолжение обсуждаемой темы: обреченность универсальных подходов, единых моделей и прочих странных вещей из это серии проистекает из-за сильного влияния на систему контекста (окружения, проблемной области…), в котором она эволюционирует. Внешние обстоятельства важнее внутренней структуры системы, т.к. именно они её формируют, под них она постоянно подстраивается. Потому мы и называем эту часть software. Эта мысль, в частности, противоречит фундаментальному подходу нобелевского лауреат Герберта Саймона (Herbert Simon), изложенному в цикле лекций Науки об искусственном (The Sciences of the Artificial), предложившему создать науки о рукотворных системах. Но для программных систем, похоже, мы остаемся в фрейме естественных наук, а задачей архитектора всё больше становится проектирование систем адаптивных, устойчивые к изменениям внешней среды чем, например, концептуально целостных