🍵

【書籍紹介】「データモデリングでドメインを駆動する」

2024/03/24に公開

er図

ドメインモデル

モデル

データモデル

idea

はじめに

当書は、データモデリングの重要性について書かれた本です。

この記事はそれを一読者が勝手に紹介する記事です。

特に基幹システムにおけるデータモデルの位置づけや考え方を、ドメインモデリングの文脈と絡めながらまとめられています。
データモデリング、ドメインモデリング、基幹システム、等の基本的な用語や一般的な使われ方、考え方は軽い紹介や前提確認程度に触れられ、そこからさらに一歩踏み込んだ、本質的な議論が展開されています。
そのため、ある程度基幹システム周りの設計の経験がないとしっくりこないかもしれません。

当書がその内容に対してかなり簡潔に体系立ててまとめられているため、本記事は当書を要約することを目指すものではありません。当書以上の圧縮は無理です。
むしろ、個人的に腑に落ちたところを抜粋しつつ私の解釈を紹介することによって、当書が購入され、考え方がさらに広まることを期待します。

免責

当書はかなり本質的かつ原則的な考え方、概念の位置づけ、枠組みを重視されているように思います。その分、深いレベルでの理解は容易ではなく、私自身が筆者の意図を誤認している恐れがあります。

わかりやすさのため、何をなぜ分けて考えるのか、を中心に紹介しますが、分けることは扱わなかったほうを軽視する意図ではないことに留意されたいです。

ご注意いただきたいのは、「分離できる」という言葉の意味合いです。これは、それぞれを別の知的関心事として分析し検討することができるという意味であって、ひとりの人はどちらか一方だけに関心を持っていればそれで十分、という意味ではありません。

(杉本啓. データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて (p. 44). )より

フォーマットをある程度変えて紹介するため、本記事の内容が必ずしも筆者の意図を汲めているとは限りません。「あれ？ここ合ってる？」と思ったら是非原典をご購入してご自身で確認してください。

大幅な解釈誤りを発見された場合、コメントに記載ください。ご指摘頂いた内容については、今後誤った解釈が広まるのを防ぐ目的で記事を修正させていただきます。

結論

当書の主張のうち、個人的に革新的だと思った内容を無理やり一言でまとめるなら、
「データモデル≒帳簿(概念)のデザインは(本来的な意味での)ドメインモデルの一部であって超重要なんだけど、軽視されがちだから見直しましょう。」です。

その背景には、ソフトウェアのレイヤ化アーキテクチャにおける「ドメイン層」をドメインモデルと同一視する傾向が存在します。この傾向のもとでは、ドメイン層を設計することがすなわちドメインモデリングであるという理解になる一方で、データベースはドメイン層のオブジェクトの単なる「永続化」手段とみなされます。そして、データモデルは、データベース設計の図的表現法と位置付けられてドメインモデルから切り離され、「実装の詳細」として設計の表舞台から姿を消すのです。

(杉本啓. データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて (p. 464). )より

では、単なる「永続化」手段、ではないデータモデルとは何で、それはどうやって設計されていくべきなのか、を当書では詳細に語られています。

内容

導入：基幹系システムの活動のシステム（SoA）と経営管理のシステム（SoM）への分離は何を解決するか

当書では、おおよそ企業活動を以下のように整理しています。
企業活動：
・SoE：顧客との関わり合いのシステム
・SoR：基幹系システム
　・SoA(Activity)：(現場)活動のシステム
　・SoM(Management)：経営管理のシステム

当書は、ユーザーによって様々な形で集計・表現されることが求められる顧客との関わり合いのシステムと、事業内で公開されており安定性が求められる基幹系システムを区別し、後者に焦点を当てています。

そして、基幹系システムをさらに活動のシステムと経営管理のシステムに分けて考えることを提唱しております。理由は大きく2つです。
　1. 異なるニーズに応えるため
　　活動のシステムは具体的な事実を記録したい(変更記録も赤黒で厳密に)
　　経営管理のシステムは様々な角度からの「集計」によって計画や見込みを作りたい
　2. 関心の分離を行い、変更の範囲を小さくするため
　　活動のシステムは現場業務の制御なので変わりにくいが、経営管理のシステムは社内の財務報告ルールが変わったときなど、マネジメント方針が変わると変わるもの

要するに、様々な切り口で集計をしたいというニーズが生まれる経営管理のシステムを、厳密に記録を残していきたい活動のシステムと切り離すことによって、モデルが変更に強くなるというわけです。

データモデルへ：活動のシステムをさらに2つに分ける

当書では、活動のシステムを業務機能と業務プロセスに分けます。

さらに、業務機能の最小単位は「残」であり、これが責務の最小単位でもあるといいます。
どういうことかというと、リアルタイムの物々交換であればわざわざ帳簿に記録しておく必要はなく、非同期であとから代金を回収したり、物品を送ったりするときに記録が必要なのだから、管理したい最小単位は必然的にその「残」の増減になるよね、という話です。(監査などユーザー視点ではないものはデータモデルの対象外です)

活動のシステムをさらに業務機能と業務プロセスに分けて考えないとどんな問題が生まれるかというと、例えば業務プロセスが重視された場合、業務機能の最小単位である残に不整合が起きやすく対処が難しくなりやすいです。逆に、業務機能が重視された場合、責務管理がしっかりしすぎて業務機能をまたぐ業務プロセスを作るときに複数の責任部署との調整が必要になり、効率が下がります。だから、両方を分けたうえで両方別々に考えることによって、業務効率化と責任分割を両方担保できるというわけです。

このとき、業務機能は業務プロセスやその一部であるユースケースに依存しないように設計しようと言われています(業務プロセスは容易に変わるため)。

こうして企業活動が切り分けられたときの、それぞれの領域を特徴に合わせて「帳簿」としてモデリングしていくことが、当書で扱うデータモデリングです。(ここはちょっと適当な表現をしましたが、書籍の中では様々な言い方がされています。)

業務と会計の分離：会計を分離する

基幹システムは往々にして、業務と会計の境界が曖昧になり、キメラ化したデータベースを持ってますが、当書では業務システムと会計システムもわけよと主張しています。
ここで言う業務システムとは経営管理のシステムの一部であり、会計システムとは活動のシステムの一部です。

なぜ分けるかというと、会計基準(報告ルール)が変わったときに、業務システムも変更しないといけなくなるのは不便だからです。そして業務システムが変わらずに会計基準が変わることは珍しい話ではありません。

DB設計からの分離：DB設計とデータモデリングを分けて考える

データモデリングとは、帳簿設計のうち、ユーザーが関心を持つものを指します。

DB設計とデータモデリングは混同されがちだが、当書では分けたほうがいいと主張されます。
DB設計には、データモデリングには考慮不要の技術的な事情があるからです。
例えば、サロゲートキーとナチュラルキーの違いなど。

データモデリング時にDB設計の技術的な問題が入ってきてしまうと、参加者は、データモデリングが自分とは関係ない問題に感じてしまい、本来エンジニアだけで完結させるべきではないデータモデリングがエンジニアのものになってしまいます。(これは、ドメインモデリングが解決したかった課題にも通じていますね)

あくまでユーザーに関係あることのみを扱うのがデータモデリングであり、両者は区別しないといけないです。

ドメインへの接続：ドメインモデリングとデータモデリングを一緒に考える

前提として、ドメインモデルとデータモデルは区別されます。
以下のようなフォーカスの違いがあります。
・データモデル：帳簿の静的構造と制約
・ドメインモデル：振る舞い

一方で、当書では、データモデルはドメインモデルの一部であると主張します。

その背景を一言でまとめるのは無理ですが、超ざっくり言えば、いわゆるドメインモデルに着目する風潮は、データモデルを軽視し、残概念に基づく基幹システムの重要なデータ構造を設計できなくなってしまう危険をはらむ、ということです。(データ不整合と戦ってきた経験のある方であれば色々思い出すことがあるのではないでしょうか。)

先程の引用を再掲します。

その背景には、ソフトウェアのレイヤ化アーキテクチャにおける「ドメイン層」をドメインモデルと同一視する傾向が存在します。この傾向のもとでは、ドメイン層を設計することがすなわちドメインモデリングであるという理解になる一方で、データベースはドメイン層のオブジェクトの単なる「永続化」手段とみなされます。そして、データモデルは、データベース設計の図的表現法と位置付けられてドメインモデルから切り離され、「実装の詳細」として設計の表舞台から姿を消すのです。

実践：どうやってデータモデリングするか

当書では様々な例が記載されていますが、ここでは1つだけ紹介します。

活動のシステムは、以下の3つに分けて考えるとうまく観点を網羅しやすい、とのことです。
・物的管理：残管理。活動のシステムの最小機能。いわゆるAccountingの意味での会計はここ
・取引記録：取引の数量や金額が記録される。活動のシステムと経営管理のシステムの補助機能。会計基準に依存しない
・会計評価：会計基準に準拠した月末や期末の集計。経営管理のシステム

例えば、在庫管理関連システムでいえば、こういったものを扱います。
・物的管理：入出庫数量の記録、実地棚卸
・取引記録：在庫増減の原因となる入出庫取引の記録
・会計評価：在庫残高と売上原価

他にも、具体的に適用期間付きデータや履歴データをどう扱うかといったところにも言及されています。

おわりに

変わりにくいもの(=本質的なもの)に依存しよう、変わりやすいものは分けて考えよう、というのはソフトウェア設計の基本であり核心かと思います。

一方で、原理原則がわかったところで、油断するとすぐに変わりにくいものと変わりやすいものは混在します。それをデータモデルという切り口から体系整理から実践レベルのプラクティスまで落とし込んでいる当書は大変勉強になります。

繰り返しになりますが、この記事は書籍の内容を代替/要約するものではありません。どんな問があって、何を解決する本なのかを紹介する意図で書きました。

「どういうこと？」と思ったら当書には図や具体例もあってこの記事の10倍わかりやすく書いてあるので、是非手に取ってみてください。