Все примеры про ограниченные контексты (DDD Bounded Context) в курсе про микросервисную архитектуру https://www.itexpert.ru/rus/services/training/moscow/detail.php?ID=8095 у меня, почему-то(!) из телекома. Перерыл массу материалов и никакие другие примеры не нравятся. Может кто видел что-нибудь интересное, не про интернет-магазин?

Пообещал в группе обсуждения этого канала выложить слайд с прошедшего вебинара об ожиданиях Enterprise-ов от микросервисной архитектуры

Если вам не хватает ИТ-архитекторов, то подумайте нельзя ли заменить их скриптами https://mxsmirnov.com/2019/06/06/architecture-as-a-code/

Вот такую вот штуку нашел http://pivio.io

Как индустрия, мы склонны предпочитать создание диаграмм, а не моделирование, в первую очередь потому, что барьер для входа относительно низок и это представляется более простой задачей. При построении диаграмм вы обычно создаете одну или несколько отдельных диаграмм, часто в произвольной нотации, используя инструменты (например, Microsoft Visio или доску), которые ничего не понимают в семантике ваших диаграмм...

Simon Brown, Diagramming vs modelling https://structurizr.com/help/modelling

Похоже, что это https://www.amazon.com/Introduction-Solution-Architecture-Alan-McSweeney-ebook/dp/B07P2NCFDQ/ первая толстая книжка по Solution architecture

Курс молодого бойца (solution architect-а) от автора книжки Alan McSweeney

А тем временем Чанака Фернандо продолжает описывать Solutions Architecture Patterns https://github.com/chanakaudaya/solutions-architecture-patterns

Тема, возникающая в связи с декомпозицией монолоита на микросервисы, которую я стараюсь обсуждать с большой осторожностью и которую не вынес на вебинар https://mxsmirnov.com/2019/05/07/monolith2microservices/

Почему DDD или capabilities based подходы при выделении микросервисов порой вызывают разочарование? Потому что идти надо не от данных и не от функционала, а со стороны пользователя. Точнее, наиболее близкого к нему API. Есть правильный REST API, между front- и backend-ом, корректно использующий методы HTTP и представляющий нормальную моделью ресурсов - можно выделять функционал, а если нет, то ничего не получится. Ограниченные контексты может и неплохая идея, но воплощается она в REST API, плюс/минус события

Когда-то, приступая к изучению DDD я рассчитывал найти набор простых, но полезных паттернов, типа Dimensional modeling Ральфа Кимбалла https://www.kimballgroup.com/1997/08/a-dimensional-modeling-manifesto/ Простая идея, раскрутившая на определенном этапе, многомиллиардный бизнес построения корпоративных хранилищ данных (Хотя непосредственно Кимбалл говорил, что централизованное хранилище не нужно). Надеюсь, что и в DDD когда-нибудь появятся свои Инмоны и Кимбаллы

Меня часто достают идеями типа единой модели данных организации или единой базы данных, в которой будет хранится всё и в правильном формате. Пришла на ум такая метафора. Представьте, что некоторая страна, изучив свою карту решила, что слишком большая часть её территории занята водой: реки, озера, внутренние моря и т.д. В рамках проекта консолидации водных ресурсов руководители страны принимают решение о едином источнике воды. Пусть это будет море, оно самое большое и все реки, озера и прочие водные ресурсы решено слить в море и осушить. А за водой теперь все будем ходить до моря, причем по очереди

Логика консолидаторов данных довольно похожа на эту

Хочу до сентября провести митап с условным названием Архитектура предприятия лайт. В основном, вот по этой бумаге Using Agile Practices in Enterprise Architecture от The Open Group (май 2019) Предложения выступить по какому-либо из её разделов: сдвиг парадигмы, гибкие практики и пр. приветствуются! Пишите @mxsmirnov ;-)

Поделюсь заметкой из канала DocOps

​​Курс по документированию REST API на русском языке.

Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.

Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.

Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)

27 августа 2019 года в 19-00 Высшая школа бизнес-информатики НИУ ВШЭ https://hsbi.hse.ru/events/open_lectures/gibkie-podkhody-v-arkhitekture-predpriyatiya/

Кто-нибудь уже успел прочитать книжку(на русском)? https://habr.com/ru/company/piter/blog/457756/

Любителям Enterprise Integrations Patterns и PlantUML https://github.com/aheil/EIP-PlantUML

Очень даже познавательный такой лонгрид о комплексном мониторинге https://brunonetid.github.io/2019/07/09/camel-observability-openshift.html Почитаю еще раз на досуге, более внимательно

Поделюсь записью выступления @evgeniy_nikonorov о том, как "продать" идею практики архитектурного проектирования на проекте, с примерами того, что работает, а что не работает и на что стоит обратить особое внимание: https://youtu.be/mabCE99ACBQ

Существуют, как минимум, три разные вещи, названные одним и тем же словом #ArchOps. Про верую рассказывает википедия в статье про DevOps https://en.wikipedia.org/wiki/DevOps#ArchOps Я бы назвал это model-driven development + автоматизированная сборка и развертывание. Вторая идея описана в блоге Archimate https://www.archimatetool.com/blog/2016/11/03/archops-a-new-paradigm-for-ea-toolsets/ и заключается в использовании практик работы с версиями, распространившимся с появлением git, для описания [целевой] архитектуры

… no “central model” because you can choose to create multiple copies of this model and sync them

И третье, про EAM + AIOps, не то чтоб описано, скорее очерчено здесь: https://www.bloorresearch.com/technology/archops/

Истинным ценителям archimate большое количество любимых картинок https://www.hosiaisluoma.fi/blog/archimate-cookbook/ Мне кажется, что особенно customer journey удался (см. рисунок)