Саша - красавчик! Такая глубина знаний вызывает восторг!
https://youtu.be/6plJseATNTw

@WatchTh15

#SoftwareArchitecure #Analysis

Proto.Actor's Realtime-Map demo has been ported to Golang.

Learn how to build real-time visualizations using the actor model with Proto.Actor
https://twitter.com/ProtoActor/status/1452306575733964808?t=JYHHNKiQifzn2kFRrUuPCw&s=19

Real-time Map displays real-time positions of public transport vehicles in Helsinki. It's a showcase for Proto.Actor - an ultra-fast distributed actors solution for Go, C#, and Java/Kotlin.
- https://github.com/asynkron/realtimemap-go

#DDD #SoftwareArchitecture #SoftwareDesign #Microservices #ActorModel #DistributedSystems #CQRS #EventSourcing

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

Actor Model - чрезвычайно мощный механизм в DDD. Vaughn Vernon написал даже отдельную книгу "Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka", и создал несколько примеров:
- https://github.com/VaughnVernon/DDDwithActors

А сейчас Vaughn Vernon работает над xoom-actors:
- https://github.com/vlingo/xoom-actors

Proto.Actor разрабатывается автором Akka.NET. Здесь он пишет почему он начал новый проект:
- https://github.com/asynkron/protoactor-go#history

Причем, начал он писать его на Golang, хотя при этом поддерживаются языки Golang, C# and Java/Kotlin.

Для меня лично реализация на Golang имеет важное значение с точки зрения сертификации. Мы присматриваемся к Proto.Actor, и при удобном случае намерены попробовать его в действии.

Ребята так же создали демонстрационное приложение на Golang с использованием Proto.Actor, которое является аналогом real-time отображения общественного транспорта на Яндекс.Картах.

Кстати, это - клон. Оригинал написан на .NET.

В век, когда даже обычных DDD reference applications на Golang можно наскрести всего пару штук, reference application от создателей Proto.Actor с использованием Actor Model представляет собою определенный интерес.

Ну и еще это событие показывает, что Golang повзрослел, и практики проектирования вошли в Golang серьезно и надолго. Времена спагетти-кода и фраз “Don’t do Java in Golang!" остались в истории.

#DDD #SoftwareArchitecture #SoftwareDesign #Microservices #ActorModel #DistributedSystems #CQRS #EventSourcing

"Specification pattern in the DDD trilemma" by Vladimir Khorikov
- https://khorikov.org/posts/2021-08-02-purity-specification-pattern/

#DDD #SoftwareDesign

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

"Nobody Needs Reliable Messaging" by Marc de Graauw
- https://www.infoq.com/articles/no-reliable-messaging/

Отдельный интерес вызвал описанный в статье кейс с нарушением согласованности (нарушением очередности доставки сообщений). Я встречал эту проблему в некоторых российских банках и брокерах, когда событие расходной операции успевает обработаться раньше, чем событие приходной операции, что вызывает превышение лимита технического овердрафта - все как в статье.

Конечно, тут речь идет уже о другой проблеме - выбор и достижение правильной модели согласованности:
- https://jepsen.io/consistency

В статье эта тема затронута, но не раскрыта.

Небольшую сложность в понимание статьи вносит тот факт, что в ней не делается четкого различия между Командой (когда отправитель осведомлен о получателе) и Событием. И не хватает взгляда с позиции достижения Low Coupling.

Но в целом, статья заслуживает внимания.

Кстати, по поводу моделей согласованности - одной из оптимальных и часто используемых моделей согласованности, которая позволяет достигнуть наибольшего уровня параллелизма при наименьших последствиях нарушения последовательности обработки, является Causal Consistency:
- https://news.1rj.ru/str/emacsway_log/562

Vaughn Vernon тоже не обошел эту проблему стороной:
- https://news.1rj.ru/str/emacsway_log/62

У меня по этой теме в свое время набралось материала на целую статью:
- https://emacsway.github.io/ru/message-ordering-in-competing-consumers/

#DDD #Microservices #DistributedSystems #SoftwareArchitecture

"if someone thinks refactoring belongs on the backlog, they probably don't understand refactoring, or backlogs, or both."
- Ron Jeffries
https://twitter.com/RonJeffries/status/1453102208887709700?t=fGEcCfNDt3hQSdVn6f7Ijg&s=19

Значение термина refactoring, действительно, зачастую понимают не все. И, возможно, именно поэтому, в треде появился термин rearchitect.

Еще Ward Cunningham говорил:

"Refactoring is not rewriting, although many people think they are the same."

"Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence - the factors are cleaner ways of expressing the same statement."

- https://news.1rj.ru/str/emacsway_log/205
- https://news.1rj.ru/str/emacsway_log/206
- https://news.1rj.ru/str/emacsway_log/207

Refactoring - это способ управления сложностью, путем декомпозиции сложности до уровня, когда отдельно взятый её фрагмент сможет быть рассмотрен изолированно в пределах краткосрочной памяти человека.

Интересно, что Grady Booch возлагал обязанность по управлению сложностью на архитектуру, говоря, что архитектура - это многоуровневая система абстракций. Где назначение абстракций - управление сложностью. С той лишь разницей, что в refactiring мы должны соблюдать условие "equivalence":

"Refactoring implies equivalence; the beginning and end products must be functionally identical."

Иными словами, refactoring не должен изменять поведения системы:

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."
- Martin Fowler in "Refactoring: Improving the Design of Existing Code"

Ну а о том, что такое Backlog, в этом канале уже было:
- https://news.1rj.ru/str/emacsway_log/499

PBI - это требование в условиях недостаточной полноты требований. Причем, требование может изменяться в процессе снижения неопределенности, а значит, как оно тогда может что-то "требовать"? Т.е. это требование-гипотеза, но его суть от этого не меняется - в текущем моменте это - требование.

Единственное требование, которое может быть достигнуто в результате refactoring - это Modifiability. Но и тут засада, ибо NFR должны достигаться совместно с FR.
- https://news.1rj.ru/str/emacsway_log/463
- https://news.1rj.ru/str/emacsway_log/464

К тому же в популярных Agile-моделях Quality уже давно стало константой:
- https://news.1rj.ru/str/emacsway_log/428

Можно ли завести Spike на refactoring? По сути - нет, так как refactoring не разделяет со Spike цели разрешения неопределенности. Хотя, поскольку в результате refactoring повышается точность оценки, то он может выполняться и в процессе Spike.

Интересно, что еще в книге "Planning Extreme Programming" Kent Beck цитировал автора твита:

"Ron Jeffries claims he can turn any technical task into a business-oriented story the customer can either schedule this iteration or not as she chooses. There's something to be said for not having any technical tasks. Once you start down the slippery slope of setting the priority for technical reasons, it's hard to stop."

#SoftwareDesign #Agile #Refactoring

Довольно неплохая библиотека от Nginx со свободным доступом:
https://www.nginx.com/resources/library/

#Microservices #SoftwareArchitecture #DistributedSystems

Сравнение брокеров сообщений
- https://docs.nats.io/compare-nats

#DistributedSystems #SoftwareArchitecture #Microservices #DDD

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

Есть желание внести немного реальной оффлайн-жизни в сообщество. Можно встречаться на регулярной основе (ежемесячно) в полуформальной обстановке, обмениваться опытом, устраивать панельные дискуссии и доклады по вопросам DDD, системной архитектуры, качества кода и процессов разработки. А после официальной части можно еще и продолжить общение в неформальной обстановке в каком-нибудь уютном заведении Москвы.

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

В офисе пошли навстречу, и даже предложили несколько вариантов размещения, в зависимости от численности.

Об офисе я уже говорил. Если кто-то пропустил, то коротко повторюсь:
🔹 https://stroi.mos.ru/news/proiekt-bts-akadiemik-poluchil-miezhdunarodnuiu-arkhitiekturnuiu-priemiiu
🔹 https://archi.ru/projects/russia/10721/biznes-centr-akademik
🔹 https://bc-academic.ru/

Основной формат встреч предполагает свободное общение, панельные дискуссии, тематические доклады и разбор вопросов от участников сообщества. Причем, прорабатывать вопросы до конца. Если вопрос нельзя решить во время встречи, то он переносится на следующую встречу, чтоб участники могли подготовиться по теории.

На данный момент, чтоб определиться с вариантом размещения встреч, мне нужна информация о том, кто и какое участие может принять в жизни сообщества. Для этого, прошу персонифицировано проголосовать по ссылке:
🔹 https://news.1rj.ru/str/emacsway_chat/2183

Сервис от Vaughn Vernon для коллективного моделирования с поддержкой Event Storming, Context Mapping и Topographic Architecture Modeling, domorobo.to обзавелся новой документацией:

https://twitter.com/VaughnVernon/status/1458335394609582082?t=TfC0aPOI5PurTj_l6xa_zQ&s=19

#DDD #EventStorming #SoftwareArchitecture

Алексей Зимарев ( @zimareff ) делает Sample application using Eventuous .NET:
- https://github.com/Eventuous/dotnet-sample

#DDD #EventStorming #CQRS #SoftwareArchitecture

go-web-app-antipatterns - Short examples of common anti-patterns in Go Web Applications.
- https://github.com/ThreeDotsLabs/go-web-app-antipatterns

Ребята из Three Dots Labs, разработчики DDD-framework Watermill на Golang, начали собирать каталог антипаттернов.

#DDD #SoftwareDesign #SoftwareArchitecture #Golang

Интересный курс по основам коммуникации: https://www.youtube.com/watch?v=mS8EKBfLS9Q&list=PL72i_EMUg8BPfZgYbUH7ack9JqNkXaNiB

Неплохое соотношение легкости изложения и информационной ценности. Без воды.

Там есть и другие, актуальные для архитектора, видео на тему коммуникативной, управленческой и социальной психологии:
- https://youtube.com/channel/UCSN7G8syJUaRiXrw1l0qk_g

#SoftSkills #Career #Management

Пролистал книгу от топ-переговорщика ФБР Крисс Водс "Договориться не проблема. Как добиваться своего без конфликтов и ненужных уступок.", и кое-что полезное для себя подчерпнул.

В оригинале называется "Never split the difference: negotiating as if life depended on it" by Chris Voss

#SoftSkills #Career #Management

​​🤝 Как добиваться своего без конфликтов и уступок?

Главным героем книжной рубрики на этой неделе стал американский эксперт по переговорам Крис Восс. Попробуем разобраться, что нужно знать о переговорах в бизнесе и повседневной жизни, а также ответим на следующие вопросы:

Что такое активное слушание?
Как создать у оппонента иллюзию контроля?
Какие бывают стили ведения переговоров?

Обсуждаем и разыгрываем книгу "Договориться не проблема" в очередном выпуске книжной рубрики. Там же — подведение итогов конкурса прошлой недели!

🎬 Смотреть видео!

Курс по микросервисам[2] я сейчас провожу примерно каждые три недели. И каждый раз практические занятия по рисованию архитектур съедают часть и без того коротких 24 академ.часов. Похоже, единственный выход жестко фиксировать нотацию. В следующем потоке устрою эксперимент с нотацией от Мэтта Макларти[1], у которого синхронные взаимодействия обозначаются прямой стрелочкой, асинхронные волнистой, запросы помечаются стрелочкой со значком вопроса (?), команды маркируются символом (!) и т.д. И, безусловно, поделюсь результатами эксперимента

[1] A visual language for digital integration
[2] Курс Микросервисная архитектура

А вот предложения по классификации интеграционных взаимодействий от Билгина Ибряма (Red Hat) https://www.infoq.com/articles/microservices-inside-out/

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