第1部　基幹系システムとデータモデルの現在的意義

第1章　基幹系システムとデータモデリング──新たなビジネス，新たな帳簿デザイン

• 1.1　基幹系システムと帳簿はなぜ存在するか
  • 基幹系システムとデータモデリングは古いテーマか
  • 基幹系システムは企業活動を指示・制御する
  • 基幹系システムの中核には「帳簿」がある
  • 新たなビジネスは新たな基幹系システムと帳簿を必要とする
  • 既成のビジネスも新たな帳簿を必要としている
• 1.2　データモデリングはなぜ必要か
  • データモデリングとは帳簿をデザインすること
  • 既存の帳簿を引き写すのではなく，新たな帳簿をデザインする
• 1.3　ERPはデータモデリングの重要性を減じるものではない
  • ERPを使いこなすには帳簿デザインの素養が必要である
  • ERPですべてが片付くわけではない
• 1.4　既存の基幹系システムを解体し，新たな基幹系システムを構築する

第2章　基幹系システムの構造──活動のシステムと経営管理のシステム

• 2.1　基幹系システムのハイレベル構造はどのようなものか
  • 基幹系システムは，活動のシステム（SoA）と経営管理のシステム（SoM）からなる
  • SoAとSoMでは，情報処理の性格が異なる
  • SoAとSoMでは，システムが変化する要因も異なる
• 2.2　活動のシステム（SoA）は現場活動を支える
  • SoAは業務機能と業務プロセスの2階建て
  • 業務機能の分割は「残」に基づく
  • 業務プロセスは業務機能を横断する
  • 残がSoAの基本である
• 2.3　経営管理のシステム（SoM）は3層構造でPDCAを回す
  • 現場に近い経営管理は，SoAとSoMを接合する
  • 中位層は業務分野別の計画管理。業務を計画し活動を調整する
  • 上位層は財務的な計画管理。ビジネス全体の資源配分を担う
• 2.4　SoRはビジネスのためにあり，SoEはユーザーのためにある
• 2.5　伝統的な基幹系システムとの比較
  • SoAとSoMの分離を追求していること
  • SoAの分割の切り口として「残」に着目していること
  • SoAに含まれるSoE的要素を分離すること
• 2.6　本書が提起する枠組みの意義

第3章　基幹系システム設計のアプローチ──帳簿のデザインとデータモデリング

• 3.1　帳簿デザインの進め方とシステム設計アプローチ
  • 帳簿デザインの手法は3つある
  • 典型的なアプローチでは，UI設計とDB設計で帳簿をデザインする
  • データ中心アプローチでは，データモデルで帳簿をデザインする
• 3.2　ユーザーインタフェース設計だけでは帳簿をデザインできない
  • 帳簿の内容と表示の設計を分離する
  • ユースケースに依存しない帳簿デザインを追求する
  • データモデリングに画面・帳票スケッチを利用する
• 3.3　データベース設計には技術的関心事が混入する
  • ユーザーの関心事に集中する
  • データモデルの等価性に着目する
• 3.4　データモデルは基幹系システム設計の核心

第2部　データモデリングの実践

第4章　活動のシステム（SoA）──残概念に基づく業務・帳簿の分割

• 4.1　残はバッファーである
• 4.2　基幹系業務と残の例
  • 残の発生と解消を紐付けるのが残管理の基本──受注残を例に
  • 残管理のためのデータ項目には必然性がある
  • 残管理方式では，残を単位として，業務だけでなく帳簿も分割する
  • データベースに保持する必要がない残もある
• 4.3　残管理のための一般概念
  • 残の管理方式には2種類ある──件別残と継続残
  • 理論残と実残
• 4.4　新しいビジネスも残に駆動される
  • 新しいビジネスモデルにおける残を見出す
  • お客様と当社の間に生じる残
  • 当社とクリーニング工場の間に生じる残
  • 残志向は実践的な帳簿デザインを生む
• 4.5　あらためて，残管理とは
  • 業務実行者の視点から
  • 業務設計者の視点から
• 4.6　SoAのデータモデリングは残から始まる
• 4.7　非同期／疎結合な基幹系システムへ

第5章　経営管理のシステム（SoM）──多次元，バージョン，ビジネス・ルール

• 5.1　経営管理のシステム（SoM）は3階層
• 5.2　財務的な計画管理
  • 存在意義──企業活動全体をアラインメントする
  • 業務構造──財務会計／管理会計を含むがそれを越えている
• 5.3　業務分野別の計画管理
  • 存在意義──日常の事業活動を指揮，調整する
  • 業務構造──計画の策定とレポーティングに加え，計画の展開という要素を含む
• 5.4　計画管理のデータモデル
  • 計画管理には多次元データモデルが向いている
  • 計画管理ではバージョンの管理が必要──Many Opinions in Many Places
• 5.5　財務的な計画管理に関するデータモデルの特徴
  • 財務的な計画管理では期間別データの扱いに特殊性がある
  • データの修正加工に関わるデータ管理に配慮する
  • 財務的な計画管理の分野で詳細データの活用が進んでいる
• 5.6　計画の展開のためのデータモデル
  • 計画展開アルゴリズムとの密接な関係
  • SoAとSoMの中間的な性格への配慮
  • SoAとの連携の密接さ
• 5.7　現場に近い経営管理
  • 存在意義──現場活動と経営レベルの意思決定を密接につなぐ
  • 解決方法
• 5.8　分析

第6章　会計から生まれ，会計に回帰する──SoAとSoMの分離，帳簿の純化と進化

• 6.1　業務システムと会計を分離しよう
• 6.2　会計基準は報告ルール
• 6.3　業務システムは会計基準に依存しないほうがよい
• 6.4　SoA機能は，物的管理・取引記録・会計評価に分割できる
• 6.5　現行の「会計」はSoAとSoMのキメラである
• 6.6　すべてが会計だった，そして会計に回帰する

第7章　ソフトウェア設計とデータモデル──用途から道具への転換

• 7.1　情報システムは用途，ソフトウェアは道具
  • ソフトウェアは情報システムより可変的なデータモデルを備える
  • なぜソフトウェアに可変性を組み込むのか──直接的価値
  • なぜソフトウェアに可変性を組み込むのか──深い意味
• 7.2　ソフトウェアのデータモデルに可変性を織り込むには
  • テーブル駆動方式
  • ドメイン特化言語（DSL）
  • 定義体方式
• 7.3　バインディング・タイムに配慮して可変性を段階的に消去する
• 7.4　可変性の追求はどこに至るのか──ジェネレーティブなソフトウェア

第3部　分散／非同期／疎結合の基幹系システムへ

第8章　帳簿の分割と結果整合性──分散／疎結合な基幹系システム

• 8.1　帳簿は分割できる
  • 業務機能間の結合は非同期が基本
  • 業務機能と帳簿は一体として分割される
• 8.2　分割された帳簿の整合性をどう確保するか
  • 帳簿内は強い整合性，帳簿間は弱い整合性が基本
  • 帳簿内で弱い整合性が適用されることもある──長期プロセス
• 8.3　帳簿整合性とそれ以外の結果整合性を区別する
  • 結果整合性にはいろいろある
  • 結果整合性は技術的概念，帳簿整合性はデータモデリングの概念

第9章　マスターの共有──エンティティとロール方式

• 9.1　分散システムでのマスター共有は密結合を生みかねない
• 9.2　エンティティとロールを分離する
  • 疎結合化のために，マスター管理と利用の関心を分離する
  • 管理対象はエンティティ，利用対象はロール
  • ロールの顕著な例──品目
• 9.3　エンティティとロールは薄い関係
  • エンティティとロールの対応付けは1対1とは限らない
  • エンティティとロールは「汎化」関係ではない
• 9.4　分離されたエンティティとロールを結合する
  • エンティティとロールは業務機能の間（はざま）で結び付く
  • エンティティはどのシステムに帰属させるべきか──マスターの集中管理
• 9.5　エンティティとロールの意義，再び

第10章　SoMとSoAの疎結合化──変わるものと，変わらぬもの

• 10.1　経営管理は活動のシステムに食い込んでいる
• 10.2　ビジネス・ルール──SoAから分離し，可変化する
  • ビジネス・ルールをSoAから分離する
  • ビジネス・ルールを可変化する
  • ビジネス・ルールは設計における不安定な要素である
• 10.3　ビジネス・トリガー──起動と実行の責務を分ける
  • イベント通知，処理判断，実行の責務を切り分ける
  • 業務処理はイベントに依存すべきでない
• 10.4　ビジネス・レポーティング──データ加工はSoMに寄せる
• 10.5　レジリエントなシステムデザイン

第4部　モデリングのファウンデーション

第11章　データモデリングの基礎理論──図的記法とメタモデル

• 11.1　モデリング基礎理論はモデリングにおける図学である
• 11.2　図的記法とメタモデルを区別する
• 11.3　代表的なメタモデルとその特徴を理解する
  • メタモデルとはどのようなものか
  • メタモデルは数種類ある
  • 代表的なメタモデル──内容と違い
• 11.4　リレーショナルモデルを基本に据える
  • メタモデルに関わらず，図的表記法はリレーショナルモデルに引き寄せられている
  • 実体やクラスと値の区別は明瞭ではない
  • リレーショナルモデルは，モデルの枠組みが生む擬似問題を退ける
• 11.5　メタモデリング──メタモデルもリレーショナルに自前で作る
  • データベースは帳簿のデータそのもの
  • データモデルは帳簿データの構造を記述する
  • メタモデルはデータモデルのデータモデル
• 11.6　リレーショナルモデルは万能ではない
  • ツリー・グラフなど大域的構造が重要なデータ
  • 集計データ
  • ビジネス・ルールを表現するデータ
  • まとめ──1件ずつで意味が完結しないデータはリレーショナルモデルの苦手分野

第12章　偶有的複雑性に対処する──論理削除，テーブル分割，時系列データほか

• 12.1　本質的な複雑さと偶有的な複雑さ
• 12.2　論理削除──DBMSの技術的未熟さに起因する複雑さ
  • 2つの論理削除
  • データの無効化
  • 物理削除の代替
  • DBMSの貧弱さ
  • データモデルで扱うべきことがら
• 12.3　テーブル分割──データモデルの等価性に関連する複雑さ
  • テーブル分割の是非
  • 等価性の視点
  • 実践面の対応──表記法とデータベース設計
• 12.4　スナップショット属性──正規化の誤解に起因する複雑さ
  • スナップショット属性とは
  • これは正規化崩しか
  • スナップショット属性はユーザー関心事
• 12.5　適用期間付きデータ──述語論理からの逸脱に起因する複雑さ
  • 適用期間付きデータとは
  • 適用基準日の選択
  • 適用期間付きデータどうしのジョイン
  • ジョインが難しくなるのはなぜか
  • 範囲指定方式の問題──閉世界仮説からの逸脱
• 12.6　履歴データとイベントソーシング
  • 履歴データとは
  • 記録自体の変化に関する履歴とデータモデル
  • イベントソーシング
  • 赤黒訂正など
  • まとめ

第13章　概念／論理／物理データモデル──ただひとつのデータモデル

• 13.1　本書のスタンス──データモデルは概念データモデルだけ
• 13.2　概念データモデルに関する理解は混乱している
  • データ表現から独立したデータモデル
  • 概念のモデル
  • 概要的なデータモデル
• 13.3　概念データモデルを再考する
  • 概念と情報構造の間に断裂はあるのか
  • データモデルは「実世界」を表現すべきなのか
• 13.4　結論──唯一のデータモデル

第14章　データモデルとドメインモデル──ドメイン駆動設計への共感と批判

• 14.1　ドメイン駆動設計の枠組み
  • ユビキタス言語はドメインモデルをユーザーと共有する
  • モデル駆動設計は分析と設計の分断を癒す
  • コア・ドメインは設計努力のフォーカスを定める，が？
  • 軽い整理──モデル重視に同意，モデルと実装の一体化に疑問
• 14.2　ドメインモデルは何のモデルか
  • ドメインモデルは解決領域に属する
  • 「実世界」は2つの要素からなる
  • 実世界に関する知見──事業過程と管理過程
  • ドメインモデルはドメインに似ていない
  • ドメインモデルは昔からある
  • ドメインモデルはメンタルモデル
  • コア・ドメイン論は，問題領域と解決領域を混同している
• 14.3　データモデルはドメインモデルのサブセット
  • ドメインモデル中の帳簿構造に関するパートがデータモデル
  • ドメインモデルの全体を俯瞰する
• 14.4　ドメイン層はドメインモデルを包含しない
  • レイヤ化アーキテクチャとは何か
  • ドメイン層とドメインモデルは同じではない
  • ドメイン層は「部分的」でもかまわない
  • ドメインモデルはドメイン層のどこに表現されるか
  • ドメイン層のAPIはドメインモデルの忠実な表現か
• 14.5　ドメイン駆動設計に共感しつつ批判する

終章　ドメインを駆動する設計

• 1　技術は，より人間的な設計を可能にする
• 2　基幹系システムは協働を成り立たせている
• 3　基幹系システムの設計は第3の知識領域
• 4　設計を担う人々
• 5　アーキテクチャ
• 6　そして，ドメインを駆動する設計へ

付録　主キー値集合を用いたリレーショナルモデル