"Domain Events" by Alexey Zimarev ( @zimareff )
https://alexey-zimarev.medium.com/domain-events-f56555258cf5

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

📝 "Дипломатия – это дважды подумать прежде чем ничего не сказать" — Алекс Дрейер

P.S.: не мог не поделиться 🙂))

#SoftSkills #Career

Скомпилировал все посты, по теме нарушения очередности (гонки) сообщений в условиях конкурирующих подписчиков, в отдельную статью:
- https://emacsway.github.io/ru/message-ordering-in-competing-consumers/

#DDD #Microservices #DistributedSystems #EIP

Гена внес хорошее дополнение по поводу атрибутов качеств:
- https://news.1rj.ru/str/emacsway_chat/935

#Agile #Career #Management #SoftwareArchitecture

Думаю, что есть комплексный атрибут качества, более важный с точки зрения скорости поставки, замечу, не разработки, а именно поставки. Этот атрибут - Flexibility

Почему так? Потому что на скорость поставки влияют кроме Modifiability ещё и Modularity, Testabilty, Deployability и пр.

Какой прок быстро менять код, если его не протестировать, не задеплоить автоматически и т.д. Важна гибкость в целом.

Также есть ещё один комплексный артибут качества - Evolvability. Есть интуитивное понимание, что Evolvability зависит от Flexibility

Таким образом зависимость я бы выстроил так: Evolvability -> Flexibility -> Modifiability

Новая статья от разработчиков Watermill: "Running integration tests on Google Cloud Build using docker-compose"
https://threedots.tech/post/running-integration-tests-on-google-cloud-build/

#DDD #Microservices

"CQRS — что делать с кодом, который нужно использовать сразу в нескольких обработчиках?", Максим Аршинов
- https://habr.com/ru/post/547746/

#CQRS #DDD #SoftwareDesign #SoftwareArchitecture

Несколько интересных сообщений про AsyncAPI:

#Microservices #DistributedSystems #DDD #SoftwareArchitecture

Спорим, что вы не знали о существовании такой спецификации? https://www.asyncapi.io/

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

Похоже, что разговоры про культуру заходят у нас не очень. Потому сегодня вернемся к технологиям. Поделюсь ссылкой на рассуждения архитектора из MuleSoft Антонио Гарроте, об описании асинхронных взаимодействий https://engineering.salesforce.com/asyncapi-and-openapi-an-api-modeling-approach-db9873695910

Для REST есть спецификация Open API. А для обмена сообщениями AsyncAPI как-бы есть, но мало кто ей пользуется.

На самом деле, я думаю, что проблема глубже и стандартизировать надо не обмен сообщениями, а обработку потоков сообщений. Но, тем не менее

Хорошая новость для AsyncAPI Эта инициатива наконец начала вызывать некоторый интерес: https://linuxfoundation.org/en/press-release/linux-foundation-will-host-asyncapi-to-support-growth-and-collaboration-for-industrys-fastest-growing-api-spec/

Прекрасная статья на тему организации работы аналитиков и архитекторов в условиях итеративной (Agile) разработки, от одного из китов в области аналитики Dean Leffingwell:
https://scalingsoftwareagility.wordpress.com/2010/03/05/an-agile-architectural-epic-kanban-system-part-2-%E2%80%93-the-model/

#SoftwareArchitecture #Management #Agile

Скомпилировал все сообщения на тему "Может ли CQRS-команда возвращать результат" в отдельную статью: https://emacsway.github.io/ru/cqrs-command-and-result/

Статья получилась достаточно тяжелой, и для подавляющего большинства специалистов такая детализация рассмотрения этого вопроса вряд ли требуется (всегда можно сослаться, например, на мнение Jimmy Bogard, чтобы аргументировать свою позицию в процессе работы).

Но если кто-то хочет получить глубокое понимание этого вопроса, то статья будет полезной.

#DDD #Microservices #SoftwareDesign #SoftwareArchitecture #FunctionalProgramming #OOP #CQRS #CQS

Код-генератор, трансформирующий AsyncAPI в Golang-код:
- https://github.com/asyncapi/go-template
- https://github.com/asyncapi/generator

Очень гармонично сочетается с генератором Golang кода по OpenAPI и C4-model:
- https://news.1rj.ru/str/emacsway_log/170

#Microservices #Golang #DistributedSystems

Не смог не поделиться. Истину говорит:

Если хочешь чтобы донатили, открой канал на Тик-Ток)) За умные мысли донатить не будут, делиться ими - твоя потребность)

Когда ты делишься умными мыслями, ты снимаешь тяжесть с себя и возлагаешь её на других)

Еще один интересный и лаконичный документ (всего 19 страниц) от Dean Leffingwell на тему разрешения противоречий между бизнес- и техническими интересами (на странице 11) в частности, и об управлении требованиями в масштабируемом Agile в целом:
https://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile-enterprises-pdf.pdf

#Management #Agile

Просматривал вчера книгу этого же автора:
- "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise" by Dean Leffingwell.

Она вышла в печать в том же году, в котором он выпустил первый релиз SAFe.

Без сомнений, эта книга окажется полезной для тех, кого интересует вопрос интеграции аналитической и архитектурной работы в Agile-разработку. Она освещает не только работу с требованиями, но и предлагает процессы, модель которых, на мой взгляд, очень хорошо подходит для случая, когда Scrum/Nexus/LeSS - уже мало, а SAFe - пока еще слишком много. Но уже назрела ситуация, когда Product Owner-а в единственном лице не хватает для возросшего количества команд, и нужно каким-то образом интегрировать штат аналитиков и архитекторов в процесс разработки.

На мой взгляд, предложенная Dean Leffingwell модель может гармонично дополнять Scrum, как это делает, например, Disciplined agile delivery (DAD).

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

📝 "At the system level, however, architecture is often coordinated among system architects and business analysts who are responsible for determining the overall structure (components and services) of the system, as well as the system-level use cases and performance criteria that are to be imposed on the system as a whole. For this reason, it is likely that the agile team has a key interface to one or more architects who may live outside the team. (We’ll discuss this in depth in Chapter 20.)"
- Agile Software Requirements Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series) by Dean Leffingwell

Этот подход в точности повторяет предложение Харлана Миллза, известное как "Метод хирурга" ( https://news.1rj.ru/str/emacsway_log/322 ), и идеально ложится на DDD и микросервисную архитектуру. Вряд ли можно придумать что-то более подходящее для микросервисных Scrum-проектов малых и средних размеров. Это своего рода "детёныш" SAFe (в прямом и переносном смыслах). Хотя, есть мнение, что современный SAFe не так уж и велик для S-Sized команд, см.:
- "Six SAFe Practices for S-Sized"
https://www.scaledagileframework.com/guidance-six-safe-practices-for-s-sized-teams/

Кстати, SAFe предоставляет четыре конфигурации из коробки, где самая минималистичная - это Essential SAFe:
https://www.scaledagileframework.com/essential-safe/

Говоря о проблемах масштабирования Agile-команд, мне очень интересной показалась ещё одна его книга, которая вышла 4-мя годами ранее:
- "Scaling Software Agility: Best Practices for Large Enterprises" by Dean Leffingwell

Ну и коль столько было сказано про SAFe, то, наверное, имеет смысл упомянуть и книгу:
- "SAFe® 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework®" by Richard Knaster, Dean Leffingwell

#Agile #Management #SoftwareArchitecture #DDD #Microservices