決定を遅延させ、選択肢を残しておく

Viewなどを実装している時に、どのRDBMSを使っているかとかは知る必要がない

Viewを実装ていている時に決定する必要はない

できるだけ遅延させることで、適切に作るための情報を手に入れる猶予ができる

また、開発段階では全てのユースケースを把握するのは困難

実装していく中で見えてくることも多い

そうしたケースに対して柔軟に対応できる様になっていると良い

具体的には、interfaceに依存させようとか、レイヤーに分けようとかいう話に繋がる

よくrepository層の意義について語れる時に、

「後からRDB変更することができるようにするため」のように説明されることがあるが、それ自体は得られる効能の一つであって、目指すべき目的ではないだろう

そういう話の仕方をすると

「後からDBを変えることなんてめったにない」

「RDBからNoSQLに変えるのは難しい」

のような的を射てない反論がなされる

順序が逆

ソフトウェアを

方針

詳細

の2つの要素に分けた時に、

方針の方が重要なのであって、

詳細は後からいくらでも変えられるべきである

つまり、方針に沿った最も適切な詳細を後から選択する

先に決定すべきは方針で、詳細の決定を遅延させる

詳細

チームメンバー

DB

フレームワーク

通信プロトコル

ライブラリ

など

ここでの「方針」とはなにか

元の単語はPolicy

決定を遅延させる中で、適切な情報の収集をし、その情報をもとに詳細の選択をする

普通にコードを書いている中で「今、めちゃくちゃ詳細書いてるなあ」という自覚がないとそもそも選択肢を遅らせるみたいなフェーズに建てない

なんだ？

interface?

概念model?

参考