目次
第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 そして，ドメインを駆動する設計へ