Новая серия коротких заметок от Кента Бека (пока не закончена), того самого, придумавшего 20 лет назад XP - экстремальное программирование, про взаимодействия двух категорий людей: тех которые что-то хотят и других, которые могут это реализовать. Ну и структурные изменения, в которых иногда нуждается развиваемая система https://medium.com/@kentbeck_7670/software-design-is-human-relationships-part-1-of-3-perspective-1bcd53855557

В Telegram появилась возможность привязать к каналу группу для обсуждения. Попробовал: https://t.me/joinchat/DOGCZU3C1uO5I9zWYGcLfg (В связи с тем, что группа https://t.me/itarchitect уже давно живет своей собственной жизнь, то для обсуждения сообщений этого канал я сделал новую)

Все примеры про ограниченные контексты (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 Почитаю еще раз на досуге, более внимательно