概念モデルデザインパターン

雑多に

名寄せパターン

基本

システム統合時に、複数のidシステムをまとめるもの

id	システム1id	システム2id
1	user_hogehoge	2003
2	user_fugafuga	5000

発展

• サービスを小分けにして売り、エンタープライズ版では統合した便利な機能が使える、といった場合にエンタープライズ版にアップグレード時、既存のアカウントを統合する
• 考え方の根底は、前方互換性もりもりに超汎用的な機能を作るより、とりあえずミニマムに機能する作れば、最終手段名寄せがあるからなんとかなる、みたいな感じ

ポリモーフィズムパターン

基本

２つの似た要素を抽象化して同じ機能が使えるようにする
GitHubにおける IssueとPull Requestは抽象化されているため、両者共通の機能が使えし、通し番号でつながっている。

例

• GitHubにおける IssueとPull Request

発展

• 明確に分別しにくい場合はタクソノミーパターンを採用することもある
• APIだけでなく、フロントエンドのルーティングにも使える
  • １つ目のURLでタイプを判別して具体的なページへリダイレクトさせる
• 見出しと詳細パターンに似たものを感じる。見出しにtypeカラムをつけ、詳細がtypeごとに異なるなど。
  • 詳細を別テーブルするか、そのまま見出しカラムにするか
    • カラムとして表現するとNullableなカラムが増えてしまう問題

タクソノミーパターン

基本

• タクソノミーはタグとカテゴリを抽象化したもの。

例

• WordPressのカテゴリやタグ
• 高度なカテゴリ機能をもつECサイト

発展

• タクソノミーパターンは強力だが同時に脆い。もし採用したくなったら一呼吸おいて、ポリモーフィズムパターンや概念モデル化できないか考えた方が良い。システムを骨(静的)と肉(動的)で例えた場合、これらの割合をちょうどよい塩梅にする必要がある。肉だけで構築されたシステムは認知的不可が高すぎる。タクソノミーは肉にあたる。
  • 例えば、AWSはタグをインスタンスにつけることでプロジェクトごとの課金割合を計算したり、スケール対象のインタンスを指定できる。一方GoogleCloudは最初からプロジェクトを分ける構築を推奨しており、ユーザーの自由度はそこまで高くない。それぞれにメリデメがある。

タグパターン

基本

• フラットなラベリング
• １つのアイテムに対して複数のラベリングが可能

例

• GitHubのIssueやPullRequestにおけるラベル
• Zennにおけるトピック

発展

• タグに対してフィルタリングするだけでなく、正規表現によってコマンドの対象要素を決めたりといった高度な使い方もできる

カテゴリパターン

基本

• 階層化したラベリング
  • たまにタグと混同して使われる
• 基本的に１つのアイテムに対して１つのラベリングのみ可能
• 構築方法にいくつか手段がある。
  • 経路列挙
  • 入れ子集合
  • 閉包テーブル

例

• 単純なカテゴリ機能をもつECサイト

発展

• １つのアイテムに複数のカテゴリをつけたくなったらタクソノミーパターンを考える。

見出しと詳細パターン

headerとdescription。めちゃくちゃ出てくる。気づかずに使っていると思う。

基本

• 共通の情報を見出しとして、各アイテムごとに異なる情報を詳細としてまとめる

例

• 注文と注文明細
• グループとメッセージ

発展

• 業務システムにおいては、契約と消し込み(契約達成)が見出しとして現れる
  • 消し込み見出しを契約見出しの１カラムとするか、別テーブルとするかは状況に応じて分かれる(両方採用している場合もある)
    • 注文に対する発送
• マスタとトランザクションの関係に近いかも

https://zenn.dev/dove/articles/c5672dda4c268e

経路列挙パターン

概念モデルというには物理設計によりすぎているかもしれないが...
一般的にはカテゴリを構築する１つとして捉えられているが、どちらかというとネストした構造をもつ複数の値を集計したいときに一番力を発揮する。

基本

• idとpathを複合PKとする

id	path	value
1	'root.sub.a'	13
1	'root.sub.b'	1

コンポジットパターン

基本

ファイルとフォルダの関係で有名なもの。無限に構造化することができる

• コンポジット(フォルダ)はリーフとコンポジットを含めることができる
• リーフ(ファイル)は他のリーフやコンポジットを含めることができない

例

• ファイルとフォルダ

EAV(Entity-Attribute-Value)パターン

物理設計に近いかも...
SQLアンチパターンではアンチパターンとされるが、表現力が高く実際に利用される。

基本

• entityIdに対してどのような種類(数字、文字、配列)の値をもつか
• 型による保証を捨てているためテストは必須

例

• 品目種別に対する品目の属性

発展

• 値だけでなく関数式自体を保管するという考え方もできる
  • Notionのデータベースで関数列を設けるイメージ
• データを縦持ちするパターンの１種
  • key-valueパターンに属性つけただけ