Пролистал книгу "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

В следующем сообщении говорится о том, почему я для 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/