tgoop.com/emacsway_log/1118
Last Update:
Один из острейших вопросов при разработке 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").
Продолжение.
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1118