データモデリングでドメインを駆動する―分散/疎結合な基幹系システムに向けて [単行本]

データモデリングでドメインを駆動する―分散/疎結合な基幹系システムに向けて の 商品概要

• 要旨（「BOOK」データベースより）

  本書のテーマは「データモデリング」と「基幹系システム」です。Ｗｅｂ上で台頭しつつある新たなビジネスは、新たな基幹系システムを必要としています。一方、既成ビジネスでは、モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン、つまりデータモデリングがいずれの取り組みにおいてもカギですが、データモデリングが真価を発揮するには、その知識体系を現代的に仕立て直す必要があります。

• 目次

  ■■第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　そして、ドメインを駆動する設計へ
  
  ■付録　主キー値集合を用いたリレーショナルモデル

• 内容紹介

  本書のテーマは「データモデリング」と「基幹系システム」です。
  Web上で台頭しつつある新たなビジネスは、新たな基幹系システムを必要としています。一方、既成ビジネスでは、モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。
  基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン、つまりデータモデリングがいずれの取り組みにおいてもカギですが、データモデリングが真価を発揮するには、その知識体系を現代的に仕立て直す必要があります。
  本書では、「活動のシステム」と「経営管理のシステム」という線引きを導入し、2つの領域で異なる帳簿特性を踏まえて、分散／非同期／疎結合な基幹系システムのための実践的データモデルを詳説します。さらには、データモデル理論の基礎にも新たな光をあてて、論理削除、テーブル分割、履歴管理といった共通論点に解決の糸口を提供し、支持を得ているドメイン駆動設計との関係性を探究します。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  杉本 啓(スギモト ケイ)
  株式会社フュージョンズ代表取締役ＣＥＯ。プログラマー。コンサルティング会社アーサー・アンダーセン（現アクセンチュア／ＰｗＣ）にて、生産管理、会計およびそれらの周辺領域で、システム開発／業務改革プロジェクト多数を推進。連結会計パッケージソフトウェアの開発責任者を務める。独立して経営管理クラウドｆｕｓｉｏｎ＿ｐｌａｃｅを開発。事業展開のためフュージョンズを創業

• 著者について

  杉本 啓 (スギモト ケイ)
  株式会社フュージョンズ代表取締役 CEO。プログラマー。コンサルティング会社アーサー・アンダーセン（現アクセンチュア/PwC）にて、生産管理、会計およびそれらの周辺領域で、システム開発／業務改革プロジェクト多数を推進。連結会計パッケージソフトウェアの開発責任者を務める。独立して経営管理クラウドfusion_placeを開発。事業展開のためフュージョンズを創業。フュージョンズ：https://fusions.co.jp/X（旧Twitter）：@sugimoto_kei

データモデリングでドメインを駆動する―分散/疎結合な基幹系システムに向けて の商品スペック