複雑GUIにおけるRepositoryパターンの勘所
#Server_State
#複雑GUI
#宣言的UIの設計レシピ
前提: ここでの
Repository
について
Web API
や外部ストレージへの
データアクセス
に関する責務を持つ
内部的には
REST
、
GraphQL
、LocalStorageなどのインタフェースで実装される
---
経験上、
GUI
において
技術的な知識
を隠蔽するという目的で
レイヤードアーキテクチャ
にしてもペイすることは少ない
SPAでのレイヤードアーキテクチャの考察と不確実性へのマインドセット
最近は
スキーマ駆動開発
がメジャーなので
API
クライアントの自動生成もできる
→
Repository
自体が自動生成されるものになっている
GUI
における
Repository
は「DBの抽象化」ではなく、「
リソース
の抽象化」である
CRUD
操作の発想にとらわれるとスケールしない
アプリケーションロジックの命名にCRUDを持ち込まない
ブログのアプリを作るとして
「記事の中身をとってくるクエリ」はユースケースやパフォーマンスチューニングなどの要件から数パターンあってもおかしくない。
同一のAPIを使った情報の表示であってもページや表示箇所によって微妙に表示の仕方が異なる場合がある
データ構造
や
Web API
がきちんと設計されてればクライアントサイドで
Repository
が必要になることはほぼない
Resource-based APIとUsecase-based APIの勘所
特に最近はコンポーネントの中でフェッチするのが主流
Render As You Fetchパターン
そこまでして守るべきビジネスロジックがフロントにはあまりない
シンプルに
ストア層とコンポーネント層をhooksでわける
ぐらいでも十分なケースがある
レイヤを重ねても開発効率が落ちるだけな時も...
多くのプロジェクトはリファクタリング耐性を必要とするくらいの大きな規模になる前に開発が終わってしまう
関心の分離はドメインとプレゼンテーションから考える(PDS)
宣言的UI
のデータ構造をシンプルにしたいなら、
ドメインモデル
や
Presentation Model
の構築を検討するほうが素直
フロントエンド(SPA)でオニオンアーキテクチャっぽくデータフェッチとドメインを分離する例
みたいに
単方向データフロー(unidirectional data flow)
を作って依存管理する
koushisa.icon
の結論→
宣言的UIのデータアーキテクチャはコンポーネントを中心に考える