「宣言的UI時代のクライアントサイドDDD大考察」の感想

示唆を与えてくれる良スライドだったのでkoushisa.iconの感想を書いていく

@koushisa: "宣言的 UI 時代のクライアントサイド DDD 大考察 / Client-side DDD in the Age of Declarative UI"

@koushisa: GraphQLやデザインに対する考察も含めて考え方がかなり近くて、感覚値だったものが言語化されててすごいすっきりした

@koushisa: 具体例に示されているように、クライアントサイドのバリデーションへの要求度合いがDDDのようにモデルで扱いたいかのしきい値となることがおおい

@koushisa: たとえばドメイン制約上のバリデーションをクライアントで表示したいとして、クライアントでしかわからない情報やリッチなGUI(カレンダー)みたいな他のステートが絡んでくる中でどうやってドメインを守るかみたいな

@koushisa: これ考えてくと自然とモデルの制約や仕様を表明するためのドメインモデルをクライアントでつくるようになる。ここはzod、yupみたいなライブラリでやると型安全性が高く開発体験もいい

@koushisa: 予約系システムのようにドメインが深くてリッチなGUIを作るときのクライアントサイド複雑化しがちなので下記のような単方向データフローがマッチするなあ

@koushisa: 簡単なGUIはAction, useReducerで分けたりしないけどドメインモデルを独立させるのは個人的に最重要視してる。保守性にダイレクトにひびく

同時期にバックエンドもレイヤを取っ払って型を生かした単方向データフロー(unidirectional data flow)でのDDDパラダイムの考察がなされている

直接関係ないが大事そうなこと

特定の状態のスナップショットを型で表現する

Actionを状態遷移の契機とする

状態遷移はReducerにする

状態について

参照

コンポーネントに依存する

局所的な処理も多いのでコンポーネントと近い位置に配置する

更新

他類似スクラップ

@koushisa: 複雑なフォームのバリデーションと変換ロジック、RHFとresolver無しでは作れない体になってしまった。schemaを分離できるの強い。

連ツイ参照