Часть 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

В следующем сообщении говорится о том, почему я для EventStorming использую Archi - чтобы с математической точностью вычислять наилучшую конфигурацию контуров микросервисов на основании принципа Low Coupling & High Cohesion:

Cranking out lines of code isn’t the most value-add activity for architects. But understanding system structures and hidden dependencies is, and debugging is all about that

Gregor Hohpe начинает 2023 год с разговора на нашу любимую тему: "Должен ли архитектор писать код" и приходит к неожиданному выводу о большей пользе для архитектора от участия в отладке: https://architectelevator.com/transformation/debugging-architect/

Обещал найти ссылку о применимости шаблона описания архитектурных решений ADR для более широкого класса решений.
Делюсь: ADR = Any Decision Record? Architecture, Design and Beyond

Краткое графическое введение в c4model от IcePanel

https://blog.icepanel.io/2022/10/03/c4-model-for-system-architecture-design/

Долгое время единственным ISO-шным стандартом по архитектуре оставался ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture denoscription. В 2019 году появились сразу два новых архитектурных стандарта 42020 и 42030. А в ноябре прошлого, 2022 года обновился и основной стандарт описания архитектуры.

Как именно, читайте здесь: https://mxsmirnov.com/changes-420x0/