Прежде чем разбирать вопросы к вебинару Проектирование по событиям, надо немного поговорить про управляемые событиями архитектуры. Сам термин появился лет двадцать назад как своего рода альтернатива сервис-ориентированным архитектурам или, если угодно, SOA 2.0 (подробнее см. Event-driven architecture) Потом много чего происходило и с термином и с управляемыми событиями архитектурами. Если разбирать всё, то экскурс получится не только обширный, но и довольно занудный.
Потому перенесемся сразу в 2017 год к выступлению Мартина нашего Фаулера The Many Meanings of Event-Driven Architecture на GoTo Conference в Чикаго. Кому лень смотреть всё выступление – в первом комментарии приведены отметки времени. Краткий обзор озвученных рассуждений здесь: https://martinfowler.com/articles/201701-event-driven.html

Частый и довольно важный вопрос, от зарегистрировавшихся на вебинар: а в чём именно разница между описаниями цифровых услуг и традиционными функциональными требованиями?

Есть много осязаемых различий. О них я подробней расскажу на вебинаре. Но есть и неявное, но принципиальное различие в подходе к дизайну услуг. Заключается оно в том, что акцент с продукта сместился на клиента. Т.е. раньше компании разрабатывали продукты. Что представляет собой продукт было более-менее ясно, но не особо понятно для кого именно нужен этот продукт. Теперь времена CustDev-а, т.е. мы намного лучше представляем для кого, но всегда представляем что именно собираемся сделать. Это довольно сильно влияет на дизайн клиентского опыта и на подходы к разработке решения. А еще между клиентом и продуктов появилась сущность кампания… Ну и т.д...

… кстати, когда госструктуры начинают рассуждать, что им нужна цифровая платформа для сокращения количества информационных систем в разных ведомствах, сразу ясно, что они еще в прошлом, а не с нами. Иначе бы они озвучивали бы тезис, что платформа им нужна для того, чтоб проще и полнее закрывать потребности разных групп клиентов, независимо от того, какое из ведомств отвечает за ту или иную часть услуги, ну или что-то подобное. В этом случае скепсиса в отношении подобных инициатив было бы меньше

17:00 MSK Проектирование по событиям: https://youtu.be/eR_PbrQ7PwQ

https://youtu.be/oMSzGc5bDr4 Программа по ссылке https://www.asyncapiconf.com/

Меня вчера спрашивали про Domain Storytelling, а в цитируемом сообщении (и том, что после него) я немного досадовал по поводу этого подхода

Поделюсь событием: T-Meetup Online: Architecture as Code
Вы не успеваете задокументировать архитектуру приложения, потому что спринт очень короткий? Тогда подумайте об автоматизации ваших ежедневных задач," — советует архитектор T-Systems Сергей Лукин
https://t-systems-russia.timepad.ru/event/1302333/

Вот какую картинку нашёл

Термин Micro-Web-Service появился в 2005 году. Его использовал Питер Роджерс, выступая на конференции Web Services Edge. Всё было выражено одним слайдом: одним из типов ресурсов сети могут быть программные компоненты, реализованные в произвольных средах исполнения, обнаруживаемые по своим URI и допускающие интеграцию в стиле Unix-like pipelines

Поработав в центральном и коммерческих банках, я довольно скептически настроен в отношении BIAN. Да и Archimate стараниями The Open Group движется в некотором, не ясном для меня направлении. Тем не менее, поделюсь новой статьей Ирины Блажиной https://habr.com/ru/post/499092/ Ведь может так случиться, что взаимодействие этих двух вещей рано или поздно принесет неожиданные, но так давно ожидаемые финансовым сектором плоды

Наконец-то! А то мы уже заждались отчета о новых и уже не вполне свежих технологиях, подходах и практиках в архитектуре и дизайне ПО: https://www.infoq.com/articles/architecture-trends-2020/

К сожалению, самые интересные на мой взгляд вопросы о том, почему ряд трендов прошлогоднего отчета, таких как CQRS, преодолели пропасть между ранними последователями и большинством, а другие, например Evolutionary Architecture, потерялись. Возможно, застряли в "пропасти"?

Мне довольно утомительно повторять идею, которую мне внушили еще лет десять назад: digital disruption – это не о том, что надо всю деятельности перевести в цифру, а скорее о том, что завтра придет какая-то неизвестная ранее компания и начнет делать некоторую, очень малую часть вашей цепочки создания ценности в десять раз эффективней, чем вы это делали сами. При этом, скорее всего платить ей за использование этой фичи вы будете в десять раз больше, чем тратили на этот шаг цепочки раньше. Потому, что это капитализм. Отказаться будет можно только потеряв часть клиентов, возможно значительную часть. Ну, просто клиенты начнут орать: почему вы не продаёте айфоны или еще что-то подобное. Главное, что требуется от компаний (и от их айтишников), четко и экономически выгодно на это отреагировать. Т.е. не раздавать айфоны бесплатно у метро, а сделать что-то чуть более осмысленное

Что-то мне подсказывает, что уже очень скоро вместо разработки и проведения учебных курсов по архитектуре ИТ-решений мне придется рисовать карточки для подготовке к собеседованиям. Как-то так: https://github.com/donnemartin/system-design-primer Ну, и еще по стопочкам их раскладывать:
- быстро,
- чуть подробнее,
- некуда спешить

В группе "Архитектура ИТ-решений" опрос о том, кто сегодня работает. На текущий момент 52 голоса. Половина ответивших не работает, а другая очень даже трудится. Причем 11% делает это в офисе

Ссылка на перевод: https://docs.google.com/document/d/1w3qb6SS1Hycyce5Fg5mVMdzkGYXTRskSf57IoD98ZQw/edit?usp=sharing Он, конечно, немного странный. Чего стоит термин "мастер-раб", но может кому пригодится

А забавное чтиво. Там и перевод на русский язык есть. В git и docs.google.