🔷 "Особенности управления изменениями в России". Книга шедевральна.

#Psychology #Management

Вот так выглядело 17 лет назад то, что мы сегодня называем ADR, и в нем описывается то, что мы сегодня называем Event Sourcing:
- https://trac.edgewall.org/wiki/TracDev/Proposals/DataModel?version=1

На что можно обратить внимание? На то, что документ начинается с описания контекста. Michael Nygard предложил это делать лишь спустя 6 лет.

Там, где автор пишет "consistent change tracking and concentrate the autorship of resource modifications in one place", он фактически описывает Event Sourcing. А здесь он говорит про функциональную природу Event Sourcing: "as this can easily be reconstructed from the full history of changes".

Но самое главное - здесь хорошо видно, что архитектурное решение является балансом противоречивых требований: "balance between generality, so that the API can be the same across resources) and specificity".

Так же описаны достоинства и недостатки архитектурного решения, в соответствии с шаблоном Michael Nygard.

Авторы Trac заметно опережали свое время. Другие их "нетепличные" идеи для структуризации ADR можно посмотреть здесь.

#Documenting #EventSourcing

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

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

Однако, в ряде регионов России в июне выпал снег ❄

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

Второй вариант - это проверить температуру на практике - выйти на улицу. Это уже эмпирический способ обработки неопределенности, т.е. опытным путем.

Допустим, вы вышли на улицу и поняли, что футболка для снега не годится. Вы возвращаетесь и адаптируете свою экипировку под реальные условия, руководствуясь новым знанием, полученным в результате эксперимента. Это называется Adaptation.

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

Станете ли вы пытаться предугадать погоду заблаговременно, если можно легко проверить гипотезу на практике? Вероятно, что нет. Тогда у вас превалирует адаптивный способ обработки неопределенности - это итеративно-инкрементальная SDLC-модель разработки, или её разновидность - Agile.

Ок, но вы живете на 150-м этаже, окна не открываются - климат-контроль. Прежде чем выйти на улицу и проверить гипотезу на практике, вы уже взвешиваете риски, чтобы минимизировать вероятность адаптации. Т.е. пытаетесь сперва разрешить неопределенность заблаговременно, путем логического вывода, и лишь затем - закрепить результат путем практического эксперимента. Это уже гибридная или спиральная SDLC-модель.

Вдруг вы узнаете, что лифт сломался и неделю работать не будет. 150 этажей пешком! Вы делаете все для того, чтобы исключить вероятность адаптации. Например, вы обращаетесь через интернет к более продвинутым моделям прогноза на основе спутниковых данных. Это называется каскадная модель разработки (BDUF) - 100% of Prediction.

У вас есть свое мнение о погоде, но вы спрашиваете мнение соседа - как он думает, какая погода на улице? Вы формируете коллективное мнение. Сосед говорит - холодно. Вы говорите - тепло. Это называется противоречие. Противоречие и отсутствие возможности проверить мнение на практике (эмпирическая проверяемость) говорит о том, что вы не знаете, какая на самом деле погода. Тут вдруг поднимается по лестнице еще один сосед с улицы. Вы спрашиваете у него о погоде - он отвечает. Противоречие устраняется, и одно из мнений проходит эмпирическую проверяемость - это называется знание.

Неверно выбранная Agile модель разработки - это все равно, что спускаться 150 этажей пешком для того, чтобы узнать как одеться перед выходом на улицу. Чтобы этого не допустить, литература по архитектуре приводит критерии выбора SDLC-модели разработки. В простейшем случае - это Cynefin framework. В более сложном случае - статьи и книги Barry Boehm.

См. также краткий справочник по SDLC.

#Agile #DDD

@gradea справедливо напомнил, что Adaptation можно сравнить с метафорой Gregor Hohpe о продаже опционов на фондовом рынке.

Пролистал книгу "Domain-Driven Design with Golang" by Matthew Boyle

Образцы кода к книге:
- https://github.com/PacktPublishing/Domain-Driven-Design-with-GoLang

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

Но для расширения кругозора полистать можно.

Кстати, я смотрю, в справочнике ссылок по DDD+Golang появилось много нового.

#DDD #Golang

А вот этот Golang DDD ES/CQRS Reference Application от контрибьюторов EventStore посмотреть было уже интересно. Многие вещи реализованы довольно грамотно. Есть на что посмотреть.
- https://github.com/EventStore/training-advanced-go

#Golang #DDD #EventSourcing #CQRS

Один из острейших вопросов при разработке frontend с применением CQRS-like State Manager (Redux, Vuex, Pinia, NgRx etc.) - это где размещать бизнес-логику, в actions или в reducers. Однозначного ответа не дает никто, и это делает вопрос интересным.

Авторы Redux затрагивают этот вопрос здесь: "Where should my “business logic” go?"

Итак, по порядку.

1. На фронте нет "бизнес-логики", если это только не offline-first и не peer-to-peer приложение. Задача UI - предоставить пользователю Read Model, чтобы он смог сформировать валидную Команду (CQRS-Command). А эта задача в корне отличается от проверки инвариантов Агрегата.

2. Ребята от IBM приходят на помощь и устраняют эту путаницу в размещении логики:

💬 "There is no concept of reducers, meaning that there is no confusion about where logic needs to reside between reducers and actions. Commands are the only place that state logic resides and return operations that dictate what state changes are required and processed internally by the store."
-- Dojo Stores

Они разработали архитектурно более правильную версию Redux, которая более понятна разработчикам с опытом в CQRS.

Вот только они не уточнили, о какой именно логике идет речь - Application или Domain, если это все-таки offline-first приложение.

Под термином Operation здесь понимается Domain Event, лишенный своей семантики. И эта подписка, по сути, тождественна подписке на Domain Event.

А здесь, по сути, осуществляется накопление Reversing Domain Events в виде компенсационных Operations.

Это лучший CQRS-like State Manager, который я видел. Но тем не менее, меня не привлекает идея превращать осмысленные Domain Event в семантически бессмысленные Operations по образу WAL. По этой причине я бы предпочел не использовать вообще никакого Vendor Lock, тем более, что ряд из них уже не раз потрясал своих пользователей обратно-несовместимыми релизами, а то и вовсе прекращением развития в пользу другого решения (например, Vuex -> Pinia, или Redux -> Hooks).

Классический Mediator по образу MediatR пишется всего за несколько минут, гарантируя независимость от потрясений любого вендора.

Резонно возникает вопрос, а где в таком случае должен быть Агрегат, ну, если он должен быть?

Агрегат должен быть при выполнении двух условий:
2.1. Domain Logic реально присутствует на стороне Frontend, см. п.1.
2.2. Frontend выполнен не в функциональной парадигме, см. подробнее здесь. Дело в том, что функция агрегата - обеспечить контроль над изменяемостью его состояния. В FP нет изменяемости, соответственно, отпадает надобность в её контроле.

Однако, мы помним, как B.Mayer сказал:

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

Почему он так сказал? На этот вопрос отвечает Eric Evans:

💬 "If the framework's partitioning conventions pull apart the elements implementing the conceptual objects, the code no longer reveals the model.

There is only so much partitioning a mind can stitch back together, and if the framework uses it all up, the domain developers lose their ability to chunk the model into meaningful pieces."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Это и есть основная проблема при использовании Redux в больших приложениях - фрагментация логики превышает возможности краткосрочной памяти человека.

Кроме того, сама суть CQS заключается в том, чтобы позволить использовать преимущества как функциональной парадигмы (Query), так и императивной (Command), т.е. комбинировать их в одной программе.

Место Агрегата в таком случае хорошо указал Udi Dahan в статье "Clarified CQRS", см. первую картинку.

В таком случае, Reducer/CommandHandler содержит логику уровня Application Layer и осуществляет действие над Агрегатом.

И здесь на первое место выходит вопрос о том, каким образом будет биндиться агрегат на его HTML-отображение. Например, можно применить самодельный View Model (см. главу "Duplicate Observed Data" книги "Refactoring: Improving the Design of Existing Code" 1st edition").

Продолжение.

Часть 2.

В рассмотренном выше варианте сам Store может хранить Доменную модель. Выглядеть это будет примерно так.

3. Есть и иной вариант, когда Command никаким образом не связана со Store и является отдельной надстройкой, а Store превращается, по сути, в обработчик Domain Events, обеспечивая биндинг Агрегата на его HTML-представление. Почти такой же вариант описывает @oleglustenkome в чате канала. И здесь.

Спасибо участникам дискуссии за замечание - я должен внести правку в предыдущее сообщение.

> На фронте нет "бизнес-логики", если это только не offline-first и не pear-to-pear приложение. Задача UI - предоставить пользователю Read Model, чтобы он смог сформировать валидную Команду (CQRS-Command). А эта задача в корне отличается от проверки инвариантов Агрегата.

Здесь имелась ввиду полноценная доменная модель вместе с инвариантами агрегатов. Потому что, если прочитать буквально, то обнаруживается противоречие, поскольку Команды тоже относятся к бизнес-логике, хотя их обработчики часто реализуются на уровне Application в силу DDD-трилеммы.

О роли однонаправленного потока изменений см. здесь (копия).

Awesome списки для выбора библиотеки управления состоянием на стороне клиента:
https://github.com/tnfe/awesome-state

Прочитал статью "Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?"

В целом, статья неплохая. Кое-что я почерпнул. Правда, материал не настолько исчерпывающий по этой теме, как "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer.

Причиной внедрения Flux в практику Facebook стала потребность в реал-тайм синхронизации состояний клиентов, и решение было найдено в виде однонаправленного потока изменений:

💬 "editing the same data by multiple concurrent actors"

Причина, по которой Redux синхронный, заключается в сложности организации Causal Consistency, когда события могут выстраиваться в случайный порядок.

Так же, как и авторы Dojo Store, автор статьи утверждает, что Action - это Команда, а не событие:

💬 "Redux looks like an event bus, but it's not. Actually, a Redux store is a combination of the Command and the Observable patterns. What we do with the store is, we send it a command object known as an action:"

Тем самым они подтверждают и мои выводы, которые я озвучил вчера в чате канала.

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

Еще одним явным отличительным признаком Команды является единственность её получателя/исполнителя.

Важный момент - данные в Store названы "моделью" (это уже второй признак в пользу "первого варианта", т.е. п.2, озвученного здесь):

💬 "the user triggers an action, its gets dispatched to the stores which generate a new model and send it to the view."

Чего не хватило в статье, так это фундаментальности. Трудно объяснить достоинства Redux, обойдя стороной достоинства CQRS.

#CQRS #Frontend

Наконец-то перенес в публичную часть блокнота заметку про отличие между Repository и Adapter (Ports & Adapters).

#DDD #Repository #HexagonalArchitectire

🔷 "Эффективные надежные микросервисы" блог компании Одноклассники

Интересный опыт.

#Microservices

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

#SoftwareArchitecture #SoftwareDesign

По результатам опроса большинство предпочитает инкрементировать версию Агрегата единожды на транзакцию, а не на Доменное Событие (на факт изменения состояния).

Хочу поделиться результатом своих двухдневных размышлений по этому поводу, которые вынудили меня изменить эту точку зрения:
- https://dckms.github.io/system-architecture/emacsway/it/ddd/tactical-design/repository/causal-consistency.html

А какие у вас соображения по этому поводу?

#DDD #DistributedSystems #Microservices #CausalConsistency