データとロジックは近い位置にまとめる
#設計原則
#スコープは小さいに越したことはない
#宣言的UIの設計レシピ
コアとユースケースにより変化する
プレゼンテーション
を分離する
なにがコアで何がプレゼンテーションなのかを区別すること
それにより
リグレッション管理
がラクになる
---
利用側に
データ構造
を意識させない
データ
に対する関数のみを公開する
データ
の宣言だけでファイルを分離させない
カプセル化
,
契約による設計
スコープが小さいとロジックの
命名
や責務もシンプルになる
データ
の
事実
、
現象
が変化する頻度は少ないがその
知識
、
概念
や
関係モデル
は変わり続ける
プロダクトを取り巻く
環境
変化
理解が深まったことによる軌道修正→
ビジネスロジック
の
リファクタリング
開発組織
の変化もある
分業
したい
別々に
リリース
したい
UI/UX
の最適化でチームを分ける
上記の変化に
プレゼンテーション
が巻き込まれないようにしたい
#DIKWピラミッド