たまたま今日、データモデルの設計についてレビューする機会があった。こういう機会って割とあるのだけれども、ざっと聞いてから、ざっと話すみたいな反射神経をもとめられるケースがおおいので、いつもやっているやり方について書いておきたい。ちなみに本論はこのビール缶を空けた時点でおわる。あしからず。
そもそもデータモデルの設計って何のためにするのか、ビール缶の2本目に取りかかっている立場でいうと、これからつくるシステムで表現可能な状態を設計するためってことになりそうである。まあ難しいことは言わないけれど、システムでやりたいことができるようにしてあげなきゃらないし、システムがやりたくなりそうなこともやれるようにしてあげなきゃならない。
データがシステムの寿命よりも長いってのは、まあおっさんの説教で聞いたことがあるのかもしれないけれど、今回のシステム開発のスコープ外だからといって、何でもYAGNIの精神で切り詰めればいいってもんでもないのがデータモデルの世界である。新しい要件がでた瞬間にデータモデルレベルで詰むみたいなシステムをつくっちゃあ、末代までの恥とされるのがソフトウェアエンジニアの世界である。
だから、データモデル設計の段階で、システムのリリース時点でシステムができなきゃいけないことはデータモデルとして当然できなきゃいけないし、システムのリリース時点ではできなくてもよいけれども、将来いかにもできなきゃいけないようなことについても、当然できるようしなきゃいけない。
そんな、簡単にいうけれど、と読者のみなさんはお考えだろう（そう考えない人や答をもっている人は対象読者ではない）。
ところがあるんだなー。もう最後ビールの一口を飲んでしまったので、簡潔に書くと下記をすればよい。
- 想定されるユースケースを一覧する
- ユースケース単位でCRUD表をつくる
ユースケース一覧をつくって、その単位でCRUD表をつくって、抜け漏れがないかをチェックすればよい。抜けがあれば、その抜けに対して、いかにもありそうなシチュエーションを考えて、「このケースはどうするつもり？」という質問を投げればよい。その質問にうまく答えられるようであれば、そのデータモデルは将来の拡張性に対して開かれているということである。
難しそうに聞こえるかもしれないが、コツを覚えれば、わりと簡単だ。たとえば、『ユーザはビールを飲む(D)』ってユースケースがあって、「冷藏庫のビール」ってモデルがあったときに、『ビールを買ってくる(C)』とかってケースはどうかについて聞けばいいだけである。
というわけで、これから皿洗いをしなければならないのでまとめるが、ユースケースとデータモデルでCRUD表をつくって、空いている穴についてありそうなケースを考えて質問すればデータモデルのレビューができるという話であった。
おやすみなさい。