読書メモ：『データモデリングでドメインを駆動する 分散/疎結合な基幹系システムに向けて』第2部
第4章
重要ワード
「残」：業務の未完了状態
「件別残／継続残」：残の種類
「理論残／実残」：期待される残と現実の残
「SoA帳簿」：残を管理するための帳簿
説明
SoAの中心は「残」であり、残の発生から消滅までを帳簿で管理する。
残は 業務を自然に分割する単位 であり、非同期で疎結合な基幹システムを実現するための仕組みとして重要。
残には
- 件別残（個別の案件に紐づく）
- 継続残（継続的に積み上がる）
があり、さらに - 理論残（業務期待値）
- 実残（現場で実際に発生している）
を区別することで業務の健全性を把握できる。
帳簿を中心に業務を捉えることで、どの業務にも「残の流れ」が存在することが分かり、新規ビジネスの分析でも強力な武器となる。
第1部よりも実務寄りの内容で、帳簿の構造の見え方が一段深まった
主張
- 残を中心に据えたSoA帳簿は疎結合性を自然に生み出す
- 残の設計は新規業務の理解とモデリングに役立つ
- SoAの本質は「残の帳簿構造」にある
感想
残という概念の一般化で、今まで見えていなかった業務の構造が見えてきた。
残の流れで業務を読み解く感覚は、他領域にも応用できそう。
第5章
重要ワード
「SoM」：経営管理（計画・実績）
「多次元モデル」：軸の多いデータ構造
「バージョン管理」：計画値改定に必須
「SoAとの責務分離」
説明
SoMは計画・実績・管理会計を扱うシステムで、SoAとは異なる要求を持つ。
特に計画値は常に改定されるため、バージョン管理は必須。
さらに、多軸集計（部門・製品・期間・地域・顧客など）を扱うため、多次元データモデル が避けられない。
一方で、経営管理のルールは頻繁に変わるため、業務システムに組み込むと硬直化する。
そのため、
SoAは事実だけを扱い、経営解釈（計画・評価）はSoM側で行う
という分離が重要になる。
業務システムに「管理会計のルールを混ぜると破綻する」という話は実務的に刺さった
主張
- SoMは「柔軟性」を中心に設計すべきで、多軸・バージョンが基本前提
- SoAとSoMは必ず責務を分離する必要がある
- 経営管理は変化するルールを扱うため、固定化してはいけない
感想
管理会計がなぜ複雑化しがちなのか、背景が理解できた。
SoAとSoMの分離は、現場でよく問題になる「どこまでを業務システムに入れるか？」問題の解決策になりそう。
第6章
重要ワード
「物的管理／取引記録／会計評価」
「帳簿の純化」
「制度会計・管理会計」
「SoAと会計要件の混交」
説明
本章は、SoA（活動）と会計（評価）が長年混ざり続けてきた問題を整理し、帳簿を純化する重要性 を説く。
SoAには本来、
- 物的管理（在庫・入出庫）
- 取引記録（発生した事実）
- 会計評価（価値付与）
の3つが混在しているが、会計評価だけは会計基準の影響を強く受け、頻繁に変化する。
したがって、
SoAは事実だけを正しく記録し、評価はSoM（会計側）で行うべき
という構造が望ましい。
これにより、制度会計の変更が業務システムを破壊するリスクが減少する。
会計処理が業務システムの足かせになる理由がクリアになった
主張
- 業務と会計の責務を分離し、帳簿を純化せよ
- 変わるもの（会計評価）はSoMへ、変わらないもの（物的事実）はSoAへ
- 会計要件を業務帳簿に埋め込むとシステムが硬直化する
感想
会計と業務を適切に切り離す思想は、長寿命な基幹システムを作るうえで避けて通れないと感じる。
「帳簿を純化する」という言葉が印象的。
第7章
重要ワード
「可変性」：変化に耐える設計
「テーブル駆動」
「DSL（ドメイン特化言語）」
「バインディングタイム」
「ジェネレーティブ設計」
説明
ここでは、データモデルを「動くソフトウェアの部品」として扱う視点が示される。
業務の変化に対応するためには、データ定義・業務ルールを可変にする 必要がある。
可変性を実現する手段として、
- テーブル駆動
- DSLによるルール表現
- メタデータ（データ定義体）
が紹介される。
そして、可変な部分を「いつ確定させるか」を決める概念が バインディングタイム。
さらに、可変な定義からソフトウェアを生成する ジェネレーティブ設計 が理想形として語られる。
会計や管理会計の変化に追従する仕組みとして納得感がある
主張
- データモデルは可変性と生成性を備えるべき
- 可変部分を定義し、必要なタイミングで確定させる設計が重要
- 長寿命の基幹システムには“変化の受け皿”が不可欠
感想
変化し続けるビジネスに対して、システム側を柔軟に保つ思想は面白いと思った
Discussion