安全にぶっ壊せる仕組みを作っておく
設計をやっていく際は、最初から正解の構造に辿り着くことは難しい
featureについてもそうだし、
featureとは、演繹的に導けるのではなく、帰納的に見いだされるもののようにも思える
Entityの定義についてもそう
APIのquery parameterの定義とかもそう
ReactのComponentの作り方もそう
設計の初期段階で演繹的に導くことを理想としてやっていきはするけど、実際は帰納的になる
実装、修正、追加をやっていく中で良い構造が見えてくる
これは業務のドメインにも依存するものなので、完全に一般化するのは難しい
他人に共有するため、再現可能にするため
修正の頻度が多いものが、少ないものに依存することで、修正が容易になる
ただこれは、「Entityは変更されることは全くない」とは言っていない
Entityもどんどん良い構造に変化していくべき
その際に、「気軽にEntityを変えられる」という状態を作ることが重要
「Entity変えちゃったら、それ以外の外部全てに影響するし、最悪デグるの怖いし今はやめとこ...」に、なってはいけない
「デグることはないので、気づいた時に良いものに変えられる」ようにしておくべき
常に「修正が入った時に、安全に素早く修正できるか」を念頭において実装する
「良い設計」はこの辺も包含しているので、良い設計をやることは、安全にぶっ壊せる仕組みを導入することにもなる 「修正容易性」とはそういう意味だしmrsekut.icon
例えば、
型をつける
依存を小さくする
Entityを小さくする
テストコード
etc.