🗂
イミュータブルでゆこう
概要
2021/11/24に開催された下記勉強会のメモです
セッション
イミュータブルデータモデルの極意
- データの種類
- Event -> 日時属性を持つ
- Resource -> ライフサイクルで属性が変わる
- イベントの7W3Hがリソースと関連を持つ
- リソース同士では依存関係があるか？ライフサイクルを同じとするかで場合分け
- リソースのサブタイプは「区分」で分類
- イベント同士の関係は時系列の並びで関係が変わる。時系列は変更してはいけない
- 例）注文に請求IDを保持、請求が決まった時に更新だと後から情報を変えてしまう事になる->中間テーブルを使う
- イベントが連なる場合はそれらを束ねたロングタームのイベントを作る
- リソースの関連とそれに関するイベントは別で識別する
- どのイベントを記録として残すか、が設計
- お金を産むもの、記録がないとお金を失うリスクがあるものを取捨選択
- 記録すると決めたイベントは変更しない
その他、参考資料
ドメイン駆動設計とイミュータブルな設計
- ドメイン駆動設計のエッセンス
- 3章 モデルと実装を一致させる
- 10章 変更を楽で安全にする設計パターン
- 15章 コアドメインに集中する
- クラス設計の方針の違い
- ドメイン駆動設計（エヴァンス本） -> できればイミュータブル
- セキュアバイデザイン -> できるだけイミュータブル
- 増田さん -> かならずイミュータブル
- 閉じた操作
- メソッドの引数と返す値の型がそのクラスの型に閉じる
- withメソッドパターン
- 状態を変えないように別インスタンスを返すsetterの代替えパターン
- イベントリポジトリ・集約ファクトリ
- 事実の記録と集約の構築を非対称にする（集約を永続化しない）
ドメインイベントの観点から再考するソフトウェア設計
- ドメインイベントは「過去に起きた」ドメイン上の「出来事」-> 後から変更できない
- 不変（イミュータブル）なモデル
- EventSourcing(ES)でなくても分析に使える考え方
- コトに注目すると全体の関係を整理しやすい
- コトは業務ルールの宝庫
- ドメインイベントをどう使うか
- EventSourcing
- 欠点もあるがソリューションでカバーできる
- EventSourcing
- プログラミングモデル
- CRUDモデル,ESモデル, AKKA-ESモデル
Discussion