Вдогонку. Фрагмент видео https://youtu.be/oUhOPcHginY
#youtube

The OpenAPI Specification (OAS) - стандарт описания REST API в виде YAML-файла.

Но YAML можно использовать и для описания микросервисов в Microservice Design Canvas. Прототип такого решения см. https://solusoftsl.github.io/microservices-design-canvas-editor/

Нашел свой довольно старый текст https://mxsmirnov.com/2014/03/20/why-ea/ и подумал, что вместо него следовало бы создать для архитекторов предприятия страничку ответов на часто задаваемые руководителями и заказчиками вопросы. Может кто видел такую штуку именно для EA?

Очень простое объяснение одного из паттернов микросервисной архитектуры https://medium.com/@volodymyrfrolov/pluggable-microservices-734457c3a3b3 Я уже говорил, что микросервисы бывают разными и изложенная в статье архитектура - лишь одна из нескольких. Но, задумываясь о микросервисах, я бы в первую очередь думал о "распределенных плагинах"

Вау! Оказывается Cloud native computing foundation с июня 2020 делает тематические технологические радары, наподобие ThoughtWorks. Сегодня появился уже второй https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/

Подробнее: https://radar.cncf.io/

В CQRS Documents by Greg Young https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf я всегда проскакивал мимо идеи о том, что анемичная модель предметной области, во-первых, это своеобразный способ обеспечения гибкости: когда ИТ-системы предоставляют россыпь объектов, которые можно как угодно модифицировать, а рабочий процесс реализован в головах пользователей и его изменение не требует доработок софта. А во-вторых - показатель бедности (Возникающие в таких системах ошибки, видимо, не столь критичны; как тактично говорит автор, эти системы имеют низкую ценность с точки зрения бизнеса)

В противоположность этому CQRS добавляет в предметную область глаголы (частные случаи команд), которые становятся полноценными элементами модели, а не только сигнатурами методов, о существовании которых никто кроме разработчиков и не подозревал

В отличии от историков, архитекторы предприятия часто перерисовывают модели будущего. Есть даже традиция разработки нескольких целевых архитектур: для горизонта планирования год, три года и совсем отдаленного будущего, например. Для структурирования унаследованных приложений и данных было бы полезным наличие нескольких горизонтов прошлого. Например, до некоторого момента времени организация структурирует своих клиентов в соответствии с предоставленными им услугами. Затем, когда услуг становится слишком много, появляется понятие кампании – ограниченного по времени предложения пакета услуг, перевязанного праздничной ленточкой. Потом приходит пора когортного анализа, целевых предложений и других подобных вещей… Всё это разные представления клиентов, разные сценарии услуг, а часто и разные информационные системы. Обобщить это в единую концептуальную модель практически нереально.

Архитектуре предприятия помогло бы мульти-концептуальное проектирование, если бы такое существовало

Разбор AWS-овских картинок от Ilograph https://blog.ilograph.com/posts/fixing-aws-architecture-diagrams-vod/ Конечно, это в первую очередь реклама собственного инструмента, но придирки к картинкам Амазона и предложения по их улучшению вполне обоснованные

Для новых подписчиков и тех, кто почему-то не знал, хочу напомнить про связанные с каналом группы:
Архитектура ИТ-решений и
Работа для ИТ-архитекторов

А заметки, опубликованные здесь, можно обсудить в специальной группе этого канала

June 2020, Philippe Kruchten:
30 years of software architecture https://youtu.be/70kyGrjs8rU
Слайды здесь: https://pkruchten.files.wordpress.com/2020/06/kruchten-2020-northrop-award.pdf

20 Октября Нил Форд будет хостить воркшоп по архитектурным катам. Если есть желание можно организовать команду и поучаствовать 🙂
https://learning.oreilly.com/live-training/courses/architectural-katas/0636920458463/

Все кто хочет поучаствовать - добавляйтесь в группу
https://tttttt.me/joinchat/CSEd5Rvy_6VeCyuZlnkGpA

Иногда небольшая доля занудства помогает разложить всё по полочкам https://www.infoq.com/articles/event-driven-finding-seams/

Недавнее от Jeanne Ross: https://sloanreview.mit.edu/article/why-you-yes-you-need-enterprise-architecture/

Следует ли расценивать появление в iOS 14 такой штуки как App Clips (в русской версии блиц-приложения) как дальнейшее проникновении идей Грега Янга о Task based UI и CQRS?

Не сумел ответить для себя на вопрос: почему в Large Scale Scrum акцент сделан на системной динамике https://less.works/ru/less/principles/systems-thinking Ведь это не единственный из способов имитационного моделирования. Есть еще, как минимум, дискретно-событийное и агентное моделирование, но о них вообще ни слова.

Намеренно ли умалчиваются альтернативы или же авторы просто ограничились чтением книжки Питера Сенге - не ясно

Оставить ли кнопку "Прокомментировать" в сообщениях канала "Архитектура ИТ-решений" или избавиться от неё, как думаете?

The Open Group выпустила стандарт Open Agile Architecture™ https://www.opengroup.org/open-group-publishes-open-agile-architecture Он довольно сильно отличается от вышедшей в прошлом году предварительной версии O-AAF, хотя и базируется на ней, включает основные темы и много чего еще. Стандарт, как и прочие документы Open Group, доступен у них на сайте https://pubs.opengroup.org/architecture/o-aa-standard/

Кому лень читать - одна из немногочисленных картинок O-AA Building Blocks. Вообще, с картинками в стандарте всё плохо, впрочем как всегда. Ну, ничего, со временем нарисуем