SPA における複雑性の境界と対処例 (執筆用メモ)
Written by guvalif.icon
※ こちらのアイデアをベースに、JSConf JP 2022 に登壇したため、更新はしません
See also: https://speakerdeck.com/guvalif/client-side-ddd-in-the-age-of-declarative-ui
参考資料
メモ (WIP)
複雑性 ≒ クライアントサイドに閉じるロジックの総量と定義
つまり品質特性を鑑みた時に、複雑性には下限が存在する (いくらでも小さくできるとは限らない)
複雑性を 0 にはできないまでも、向き合いやすくするためにモジュール分割やレイヤリングが導入される
ミニマムな複雑性 (ロジックを持つ必要性が無いケース)
View は宣言的 UI 指向のライブラリで作る
API からは Read Model として最適化された Response を返す
View は取得した Read Model をそのまま投影するだけ
Typical には、GraphQL × React で達成できるやつ
参考資料で言及されているのもこれ
引き続き考慮しなきゃいけないこと
ロジックがないからと言って、設計を軽視していい訳ではない
e.g. 情報設計と、Component の対応づけ (Component as Design System)
e.g. ビジネス要件に現れる概念と、Component の対応づけ (Component as Ubiquitous Language)
e.g. Read Model を構築する BFF 相当の層の設計
Q. これはバックエンド・エンジニアの仕事では？
A. UI の変化に応じて Read Model も変わりうるので、クライアントサイド・エンジニアが設計できることが理想的
単体のシステムに閉じた複雑性 (ロジックを持つが、他システムとの連携が必要無いケース)
考慮しなきゃいけないこと
クライアントローカルな State に関する、永続化対象との同期戦略
複数のシステムに開いた複雑性 (ロジックを持ち、かつ他システムとの連携が必要なケース)
考慮しなきゃいけないこと
腐敗防止層の設計