[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. ミドルウェア&ハードウェア

• PostgreSQL にするか
• オンプレにするか GCP にするか
• t2 インスタンスにするか

注意事項

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

具体例

あるプロジェクトで、暗黙の前提として「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 とかくらいか