"Data Mesh" by Zhamak Dehghani

Released April 2022
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781492092391

https://www.oreilly.com/library/view/data-mesh/9781492092384/

#SoftwareArchitecture

"Multi-cloud: From Buzzword to Decision Model" by Gregor Hohpe
- https://architectelevator.com/cloud/multi-cloud-decision-model/

Architects aren’t there to make all decisions. They help others make better decisions by sharing models. Let’s do that for a major enterprise decision: whether to cloud or multi-cloud.

📝 "Architects aren’t the smartest people in the room. Their primary job is to make everyone else smarter, for example, by getting folks to see more dimensions."

Хорошая статья.

#SoftwareArchitecture

"Gregor’s Law" by Gregor Hohpe

Excessive complexity is nature’s punishment for organizations that are unable to make decisions.
- https://architectelevator.com/gregors-law/

#SoftwareArchitecture

Возвращаясь к определению Bounded Context от Alberto Brandolini:

"A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views."

, невольно начинаю думать, что перевод "Ограниченный" полисемантического слова "Bounded" , возможно, был выбран не совсем удачно. Есть предположение, что термин "Связанный" контекст лучше передает смысл.

На такую же мысль меня наводят и фразы:

"Bounded context means different models of the same thing (e.g., books, customers, etc.) and is represented by models and software that implement those models."

Иными словами, Bounded Context образует связанность между программируемой моделью и её сущностью реального мира.

Следующие две фразы трактуют термин "bounded" именно как "связанный":

"How to minimize inter-bounded context dependencies?"

"The components of complex systems are bounded sub-systems or agents that adapt or learn when they interact."

А следующая фраза говорит о том, чем именно "связаны" (т. е. скованы) команды. Кстати, слово "скованный" - один из вариантов перевода термина "bounded".

"The scope of each team was bounded by their business line and their products."

Следующие две фразы говорят о том, каким именно образом происходит "сковывание":

"Bounded contexts aligned with data source domains, such as fixed-income trading or consumer lending"

"Bounded contexts aligned with consumption domains, such as accounting or liquidity"

Эта идея немного рушится фразой:

"A bounded context is the boundary for the meaning of a model."

Но тут можно вспомнить, что термин "boundary" полисемантический, и означает также "межу" или "грань". Обратите внимание на фразу "boundary for the meaning". Не "boundary of subsystem", а "boundary for the meaning", что привязывает реализацию (solution space) к её "предметному смыслу" (meaning of a model). Т.е. главное не ограничить абы как подсистему, а привязать её к доменному толкованию. Именно это Alberto Brandolini и назвал "obligation to maintain integrity".

"bounded contexts delimit the applicability of domain models. As such, the bounded context is within the solution space."

Все цитаты из AO-S.

Что думаете? Какие мысли по этому поводу?

Наверное, самая краткая и понятная картинка по мотивационным элементам Archimate, которую я когда-либо видел: https://mellarius.ru/architecture/levels%20-%20motivation.png

#SoftwareArchitecture #ArchiMate

Часто спрашивают про альтернативы для Miro. В Archimatetool есть доска со стикерами (см. New Sketch View на стр. 110). Можно делать EventStorming обычными стикерами, а не только используя "C.1.10 Business Process Cooperation Viewpoint". При этом становятся доступны историрование, версионирование, восстановление, коллективная разработка, трассировка изменений, при этом информация не покидает периметра безопасности, on-premise, а доступ к информации задается обычной конфигурацией git-сервера.

#EventStorming #DDD #Microservices #SoftwareArchitecture #ArchiMate

Grady Booch - Software Architecture for a Post AI and Post Quantum World
- https://youtu.be/MyVKoV1Nru8

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-11.aspx

#SoftwareArchitecture

Simon Brown - Visualising Software Architecture with the C4 Model
- https://youtu.be/I3F7G5yxzqs

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-4.aspx

#SoftwareArchitecture

Mark Richards & Neal Ford - Modern Tradeoff Analysis For Distributed Architectures
- https://youtu.be/mT7CT2Sg_L8

- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-6.aspx

#SoftwareArchitecture

И куча других интересных видео:
- https://iasaglobal.org/Public/Public/News/News.aspx

[UPDATE]: если у кого-то не работает, то все видео здесь:
- https://m.youtube.com/c/IasaGlobalVideo

#SoftwareArchitecture

Самое долгожданное событие в архитектурном мире наступило - материалы монументального многолетнего труда в области управления сложностью, одного из лучших авторов современности Vladik Khononov ( @vladik_kh ) начали выходить в публичность:
- https://youtu.be/d6BeLhm3a0s

Предыдущая его книга стала самой понятной и популярной в области DDD. До появления его книги разобраться с трудами Эванса и Вернона можно было только ценой титанических усилий, что сдерживало распространение DDD.

Новая его книга консолидирует труды Larry Constantine, Tom DeMarco, Meilir Page-Jones, David L. Parnas, Robert C. Martin, и вооружает нас принципом, способным легко отыскивать победные решения в задачах любого уровня сложности.

[UPDATE]: Ждем вторую часть этого keynote с ddd europe - "fractal geometry of software design". Через пару месяцев должны опубликовать.

#SoftwareDesign #MSA #DDD #SoftwareArchitecture

Diagramming with pure *.txt files:
- https://youtu.be/cIuX87Xo8Fc

Думаю, что фанаты ADR на *.md это оценят.

#SoftwareArchitecture #Emacs

💬 "Дисциплина - это действие сдерживающих начал в действии личности" -- А.С. Макаренко "О воспитательной системе"

Великолепное определение, хорошо понятное мне исходя из принципов разрешения противоречий в архитектуре.

Вообще говоря, грань между архитектурой, управлением и педагогикой (поскольку процесс обучения в нашей отрасли бесконечен) очень условна.

#SoftwareArchitecture #Management

💬 "Дисциплина часто противополагается свободе. Это дико. Свобода не воля. Воля - это уединенная возможность всякого действия. Воля - понятие, противоположное неволе, плену, связанности. Свобода - это социальный институт, это не уединенная позиция в небесах, а часть блага общего. Если я имею свободу, то имеет ее и мой сосед. Иначе говоря, она не результат моего уединения, а именно результат общественного договора. Свободу нужно противополагать произволу. Дисциплина в обществе, направленная к ограничению произвола, ставит меня в точное отношение ко всем элементам общества и тем самым позволяет мне точно учитывать обстановку и точно выбирать действие. Воля - это ваш бег в пустом пространстве. Свобода - это ваше спокойное движение по Тверской или Невскому, когда вы уверены, что трамвай идет по рельсам, автомобили и рысаки держат праавую сторону, а семиэтажные дома выстроены под наблюдением строительных законов и не обрушатся на вашу голову."
-- А.С. Макаренко "О воспитательной системе"

Очень точное высказывание, проливающее свет на псевдо-дилемму Agile vs. Architecture. Архитектура противостоит произволу, а не свободе.

#SoftwareArchitecture #Management

Вопрос к тем, кто использует ADR и считает полезным. Как вы решаете проблему, описанную @mxsmirnov здесь: https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=40m30s на 40:30?

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

#SoftwareArchitecture

Возвращаясь к вопросу, который озвучил @mxsmirnov . Полный контекст вопроса https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=38m20s начинается с 38:20.

Максим обращает внимание на то, что архитектурное решение - это ассоциация в архитектурной модели, причем n-арная.

Иными словами, ассоциации находятся не между ADR, а внутри ADR между мотивационными элементами (требованиями, ограничениями, целями, драйверами, стейкхолдерами и т.д.).

Причем, часто архитектурное решение является результатом разрешения противоречивых или обратно-коррелирующих требований.

Хороший пример приводит Игорь Беспальчук: "Пилоту нужно уворачиваться от зениток, а бомбардиру нужно чтобы вели ровно, чтобы лучше прицелиться. Конфликт неизбежен и успех в поиске баланса."

Другой пример - добавили mtls - повысили безопасность, но ухудшили performance.

Какая причина появления ADR? Как писал сам Michael Nygard https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions , он пытался найти баланс между тяжеловесностью традиционной архитектурной документации и её полным отсутствием в условиях Agile.

О чем это говорит? Почему в Agile требования выражаются чаще всего посредством PBI (Story)? Почему не делают спецификаций и трассировок? Потому что трассировки нужны для предвидения (prediction) последствий решения, в то время как Agile основан на итеративной модели, где основной способ обработки неопределенности осуществляется опытным путем (adaptation). Long read по теме:

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/models/agile/agile.html

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/balancing-prediction-adaptation.html

Иными словами, Agile был ориентирован на проекты, где создание артефактов для заблаговременного (prediction) разрешения неопределенности путем логического вывода себя не оправдывает экономически, ибо дешевле, как говорится, проверить "методом тыка" (adaptation).

Отсюда вывод - если сам способ выражения требований в Agile (PBI) не обеспечивает трассировки (связи между PBI являются зависимостями, а не трассировками), то и в ADR она и подавно не нужна.

Если мы посмотрим на дату статьи Michael Nygard, то увидим 2011 год. О чем это говорит? Это говорит о том, что в это время на рынке происходит рост сложности и размера среднего проекта. Именно по этой же причине на рынке возникает запрос и на микросервисы, и на гибридные SDLC-модели разработки (цель которых сводилась к снижению доли Adaptation в пользу Prediction). Dean Leffingwell в 2011 выпустил книгу Agile Software Requirements и первый релиз SAFe.

Примерно через пару лет Brandolini изобретает Event Storming, потому, что:

💬 "...iterative development [на тот момент стал - прим. мое] is expensive. It is the best approach for developing software in very complex, and lean-demanding domains. However, the initial starting point matters, a lot. A big refactoring will cost a lot more than iterative fine tuning (think splitting a database, vs renaming a variable). So I'll do everything possible to start iterating from the most reasonable starting point."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

💬 "Upfront is a terrible word in the agile jargon. It recalls memories the old times analysis phase in the worst corporate waterfall. Given this infamous legacy, the word has been banned from agile environments like blasphemy. But unfortunately ...there's always something upfront. Even the worst developer thinks before typing the firs line of code."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

Еще через пару лет выходит статья "Insights from 15 Years of ATAM Data: Towards Agile Architecture". ATAM в Agile!!!

Появляется MiniQAW.

Таким образом, был конкретный рыночный запрос на рост доли Prediction в обработке неопределенности в силу роста размера среднего проекта на рынке, который Michael Nygard пытался решить путем введения компромиссной формы документирования, о чем он сам же и говорит.

Продолжение следует...

Блог автора книги "Mastering Archimate":
- https://ea.rna.nl/
Есть что почитать.

#SoftwareArchitecture

🔷 "Architecture vs. Design" by George Fairbanks. Интересные размышления.

#SoftwareArchitecture #SoftwareDesign