基幹系システムとデータモデリング

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

帳簿

日々の経済活動や取引の記録に使用される。
財務状況や業績の追跡に役立つ。
元帳、日記帳、買掛金帳、売掛金帳などが含まれる。
資産、負債、資本、収入、費用などの財務情報を体系的に管理する。
主な目的は異なるタイミングで実行される業務を紐づけること
SOR(System Of Record)
単に記録自体が目的ではなく、活動を指示・制御する手段として記録している

データモデリング

基幹系システム

企業の活動を指示・制御することを目的とする情報処理システム
- 必要になるのが帳簿
  2つの区分（この書籍固有の表現）
SoA(System of Actions)：活動のシステム
SoM(System of Management)：経営管理のシステム
これらは異なる要因で変化するので、ソフトウェア設計で用いられる「関心の分離」の適用例
例) 在庫の現物管理と適正在庫水準の維持は管理が異なる

SoA

2階層に分かれる

業務機能の分割は「残」に基づく

3層構造

帳簿デザインの進め方

一般的なシステム設計

データ中心アプローチ

データベース設計（内）
- プログラム設計（内）
  - UI設計（外）
  - 処理機能設計（外）
データモデリング（外）
プログラム設計がデータベース設計に依存（データベース設計をもとにプログラムを設計）
外部設計=ユーザーが関知すること
データモデルが永続化データ（データベース）に関するユーザーの関心事を扱う

UI設計ベースだけではなぜだめなのか
ここの画面や帳票は帳簿データを特定の視点からのみ表示するのが普通であり、画面・帳票は部分的である。
そのため帳簿データの構造自体を、画面・帳票から切り離した別の対象として設計する必要がある。

ユースケースに依存しない帳簿デザインを追求する
- ユースケースは複数存在するが、帳簿は単一
  - 業務の流れに対して横断的な要件を満たすために帳簿は存在する
    => 業務プロセスとユースケースに依存した不安定な画面と、ユースケースに依存しにくく安定的な帳簿のデザインは分離して考える方が良い

3の利点

画面や帳票のデザインは、ユースケースに依存
帳簿の構造は、ユースケースに依存しない（業務要件(残)に依存）

データモデルは技術的関心ごとから分離する、ユーザーの関心ごとのみを扱う
データモデリングをDB設計の際にやってしまう、包括してしまうがなぜだめなのか？
それはDB設計には技術的関心ごとが混入するため

データモデリングはユーザーの関心ごとに集中
データモデリングをDB設計とは異なる設計としておくのは、帳簿デザインに関するユーザーの関心ごとに集中する場を設けたいから