#設計原則 #スコープは小さいに越したことはない #宣言的UIの設計レシピ

コアとユースケースにより変化するプレゼンテーションを分離する

なにがコアで何がプレゼンテーションなのかを区別すること

それによりリグレッション管理がラクになる

---

利用側にデータ構造を意識させない

データに対する関数のみを公開する

データの宣言だけでファイルを分離させない

カプセル化, 契約による設計

スコープが小さいとロジックの命名や責務もシンプルになる

データの事実、現象が変化する頻度は少ないがその知識、概念や関係モデルは変わり続ける

プロダクトを取り巻く環境変化

理解が深まったことによる軌道修正→ビジネスロジックのリファクタリング

開発組織の変化もある

分業したい

別々にリリースしたい

UI/UXの最適化でチームを分ける

上記の変化にプレゼンテーションが巻き込まれないようにしたい