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

SoAは「残」を管理するためのもの
- 残在庫、残未発送、など
よくあるシステム設計
- UI駆動
  - ユースケースは変わりがち
  - 画面間で不整合が発生する可能性
- テーブル設計駆動
  - 技術的要件次第で変わる
    - 例えば、フレームワークがサロゲートキーしか使えないなど
データモデルはユーザーの関心事に注視する
- それをどう表示するか、というだけ
- テーブル設計が異なっても、同じ表現ができればデータモデルは「等価」である
  - テーブルを分けるかどうか
  - RDBvsNoSQL
「残」は業務間でのデータ受け渡しを表す
- pubsubみたいだな
情報システムの設計者から見る現実世界は2つの下位要素がある
- 物理的な物体(船舶、コンテナ)
- 情報(注文、請求、在庫管理)
ドメインモデルとは、ドメインのモデルではなくドメインで扱う道具のモデルのこと
- ドメイン層とドメインモデルは別物(ドメインモデルはドメイン層の一部)
- ドメイン層には実装起因のコードも入る　例えばgetInvoiceなのかinvoices.getBy(consumer)なのか
データモデルはドメインモデルの一部計算処理などはドメインモデルだがデータモデルではない

システムを柔軟な設計にしておくと、開発者とユーザの間使役性が上がる（一方的にならない）システムの道具性が上がり、ユーザの創造力がかき立たされる→スプレッドシートなどはそうだよねドメイン特有の知識をユーザ側に任せることができ、システム内部がシンプルに保てる

1.テーブル駆動設計条件ではなく属性でクラスを作る 2.DSL 内部DSL(実行環境と同じ言語) 外部DSL(実行環境とは違う言語)

外部DSLだとクラッシュしたときにアプリケーションに影響が出ない

3.定義体

ユーザが定義するデータモデル

EAVパターン(entity-attribute-value) キーバリュー的に自由にユーザに入力してもらう SQLアンチパターンでアンチパターンとして取り上げられているが、要は使い所次第

画面定義体 DSLなどで、ユーザが画面に表示する項目を変える

帳簿内の整合性はトランザクションによる強整合帳簿間の整合性は結果整合結果整合には転記ステータス管理など、工夫が必要なお書籍内では結果整合はデータベース上の技出的要素であり、データモデルとしては持ち出さない（ユーザに見えるかどうか）としている

マスタデータのシステム間の共有について、システムが変わればエンティティのロールも変わる例えば、従業員人事システムでは従業員だが、経理システムでは支払先例えば、品目販売可能品、在庫品など

１つのエンティティが複数ロールを持つこともある（口座A, 口座B

汎化ではない両者に依存関係はない

ロールの付加はどちらの責務でもないため、両者の間に薄いシステムを持たせて責務を担わせるのがいい人事システムに口座情報という知識を漏らしたくない場合はマスタデータ管理システムを置くパターンがある

kterui9019のブログ🪴