DB設計なんじゃらほい

DB

[2019/02/17 追記]

下記の文章ではDB設計とドメインモデリングを混同しており、根本的な誤りを含んでいることに気づいた。

修正しておらず誤ったままだがメモとして残しておく。

DB設計ってのをほぼやったことがない。 概念設計/論理設計/物理設計などという言葉が錯綜していて混乱したが、以下の5つに分けると理解しやすい気がしたのでメモ。

設計の種類

1. ドメインモデル
  • 業務はどのようにモデル化されるか
  • 業務はどのような概念とその相互作用によって十分に表現されるか
2. entityやらvalue objectやら
  • システム上でどのようなオブジェクトの相互作用によって処理を実現するか
  • それぞれのオブジェクトのattributeはアプリケーション上でどういう制約をもつか
  • 「オブジェクト指向の世界の在り方」といえるかも
3. オブジェクトとデータベースの対応づけ
  • 「entityやらvalue objectやら」と「データベースの構造」をどうやって対応づけるか
  • 「ActiveRecordパターンで1対1対応させる」とか「Repositoryでよしなに」とかの選択肢があると思う。
  • 「インピーダンスミスマッチとの向き合い方」と言えるかも。
4. データベースの構造
  • RDBにするかKVSにするか
  • どういうテーブルがあってどういうカラムをもつか
  • それらのカラムがRDB上でどういう制約をもつか
  • （RDBの場合）「リレーショナル指向の世界の在り方」と言えるかも。
5. ミドルウェア&ハードウェア

注意事項

  • 1と2は似ているようでいて実は違う。
    • 「どのようなドメインでも様々なモデルで表せます。そしてどのようなモデルでも様々な方法でコードに落とし込めます。」*1
  • レイヤーでいうと上記の1=>5の順だけど、設計作業の順番は必ずしも1=>5ではないと思う。
  • 各項目は必ずしも互いに独立していない
  • 2,4,5は意識的に考えないとつくれないが、3は割と無意識的に決まっちゃうこともあり、1については（少なくとも意識的には）全く考えないこともできる。

具体例

あるプロジェクトで、暗黙の前提として「RailsだからActiveRecordパターンね」という決めがあったとすると、それで予め3が決まる。

すると2と4は基本的に直結する*2ので、2と4の作業はひとつの設計作業として行われる。

1はよく考えなかったとする。

この場合、やった設計作業は「テーブル/クラスの構造を決める」と「ミドルウェア&ハードウェアのことを決める」の2つになる。

もちろん別のプロジェクトでは1,2,3,4,5を別々に考えて、5つをくっきり区切って設計作業を行うということもありうる。

「XX設計」との対応

まあムリに対応づけることもないけど、ぱっとでてくるサイトでの説明と見比べると、以下のような感じかと思う。

  • 「概念設計」 <=> 1. ドメインモデル
  • 「論理設計」 <=> 2. entityやらvalue objectやら + 3. オブジェクトとデータベースの対応づけ + 4. データベースの構造
  • 「物理設計」 <=> 5. ミドルウェア&ハードウェア

...というようなことをつらつら考えたが、DB設計といふものをやったことないからまずは実践してみませう。

*1:"Domain Driven Design Quickly"

*2:直結しなくなるのはSTIとかくらいか