CQS
#TODO #宣言的UIの設計レシピ #設計
https://en.wikipedia.org/wiki/Command–query_separation
ReadModelとWriteModelを分ける考え方
CQRSの観点から考えるGraphQLのスキーマ設計
Immutable Model
アーキテクチャレベルに適用させたものはCQRS
GUIでは代表的なものにReduxがある
CQSやStateモナドをGlobal State向けに実装した
CRUDにおいて、ReadとWriteでは関心が違う
https://speakerdeck.com/qsona/architecture-decision-for-the-next-n-years-at-studysapuri?slide=35
https://scrapbox.io/files/634c7bf7922c50001d4f5d92.png
ReadModel
トラフィックが多い
ドメインロジックはほぼない
あったとしてもPolicyぐらい
副作用は原則として持たない #冪等性
テストも重要ではない
読み込みに関してドメインモデルは必要ない
読み込みの機能には抽象化層がほとんど必要ないため単体テストを行う意味がない
結果整合性
子の目的に応じて柔軟に取り出せるインタフェースがほしい
Selectorのような概念が欲しい
→stateの形を考える際、「表示にとって都合のいい形を考えなくてよくなる
ユースケースが増えやすい
Write系の変更時にはRead系へのリグレッション管理が大事
非機能要件による局所最適化が必要となるケースが多い
再利用性を考えるのが難しい
非同期処理が多い
リアクティブステート参照の勘所
WriteModel
トラフィックは多くない
更新系処理はデータ構造やサービス特性と密なのでドメインロジックが多い
強整合性
副作用が主
複雑性が高い
サービス固有のドメイン知識が必要
テスト容易性が重要
Read系と比較するとユースケースの増加は緩やかだが変更が難しい
リアクティブステート更新の勘所
ほか
通知サービスに必要な要件
一般的にWriteModelは依存関係が複雑になる
機能は追加よりも変更したり削除するほうが難しい
Domain Modeling Made Functionalではビジネスイベントとワークフローに注目して分解する
GraphQLはドメインの概念の関連をフィールドで表すだけで素直に表現できる