『データモデリングでドメインを駆動する』

https://gyazo.com/531279fc745164725cbaa578893b8e69

2024/2/24

感想

はじめに

データモデリングは、デジタ ル時代に即した新たな帳簿をデザインする営為です

はじめにはほぼ何を言ってるかわからん

後を読んでみた後に読んでみるとよいまとめになっているのだろう

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

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

本書では、計算機に委ねるか人手で対応する かは問わず、企業の活動を指示・制御するための情報処理のしくみ=シ ステムを「基幹系システム」と呼びます。

データモデリングとは、端的にいえば帳簿をデザインすることなのです

端的すぎない？と思ったが、本当にこの意味で使ってるらしい

帳簿をモデリングしたものを「データモデル」と呼んでる

データ同士の関係性を描く、ER図みたいなイメージか

新たなビジネスを生み出すというのは、新たなお金の流れを作るということ

既成の帳簿をそのまま電子化するのではなく、そこでうまく設計しなおす

統合よりも分散型の基幹系システムが強くなってくる

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

https://gyazo.com/c7cb613191b70e3bf65f01e7af60d355

SoAとSoMは一般的な用語ではない

この2つは扱われ方が異なる

業務機能の最小単位

伝統的な基幹系システムと、本書の基幹系システムの枠組みの比較

SoMとSoAを区別

SoAの最小単位は残

業務プロセスではなく、機能・残を軸にする

業務プロセスでの責任の所在の明確化

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

UI設計やDB設計ではなく、データモデルを用いて帳簿をデザインする

https://gyazo.com/f26d2d46363b78bdf7d3d4c49f6acbb6

まずデータモデルがあり、その側面をユースケースごとに切り取ったものがUIになる

データモデリングはユーザに表出する外部設計である

ユースケースに依存しない帳簿デザインを追求する

これは他の業務を対象にしたサービスでも採用すべきアプローチだとは思うが、特に基幹系システムの場合は、第2章での話が前提にあるので説得力がある

つまり、SoMとSoAを分離したうえで「SoA側は変化が小さい」という観察から上手く適用できるということ

データモデリングは、ユーザ視点の帳簿デザインと言い切るの良いね

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

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

例え

バックログは帳簿

バックログアイテムは開発残、指図

完了記入は消込

そのビジネスの中の残を漏れなく発見するのが重要そうだ

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

微妙に自分の業務と結びつけるのが難しい

そういうところまで手を伸ばしたいと思いつつもまだできてないので自分ごとにできていない

例えばこういう視点で見てみるとよいか？

自分が1つの部署のトップとなり、具体的に売上を作る

データ基盤を作る視点として、どういうデータを提供するのが有益かを考える

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

「SoA機能は、物的管理・取引記録・会計評価に分割できる」というタイトルで、

3つ目の会計評価は、「SoMである」と書いているの意味わからんやろ

なんでわざわざ新しい用語を導入したの？

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

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

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