システムの振る舞いを設計する際はコトに着眼する
#イベント駆動 #設計 #設計原則 #DB設計 #モデリング
/mrsekut-p/ヒト/モノ/コトに分ける
システム外部の振る舞いをモデリングする際はコトから理解すると事実関係を整理しやすい
ユーザーは何がきっかけでシステムを利用する?
無いとどうなるか?
代替手段はあるか?
コト=現実世界で起こる事実に着眼する
ドメインイベント(Domain Event )
その前後はなにがあるか
ルーティン化していることがあるか
推測するな計測せよ
ソフトウェアデザインの対象となる3つのモデル
システム内部をモデリングする際はモノから考える
もっとも依存の小さい末端から考える
カプセル化と外部から観測可能(public)なインタフェース設計
コトとモノの関係(relation)や関連(relationship)を見出す
現実世界をシステムの世界へ投影する形でモデルを作り、問題空間を分割していく
コトの時空の把握と、その前後に反応するモデルの洗い出し
複数のモデルが同じコトを共有するなら一つのモジュールにできないか
いまは境界があったとしても、あとからくっつくかもしれない
状態設計から「なんとなく」を無くそう
プログラム以外にもあらゆる観点でメンタルモデルと一致した状態を目指す
EventStormingとドメインイベント(Domain Event )をモデリングの出発点とする
DFDをつくっていく中で、集約(Aggregate)を発見できる
集約を発見できると、サブドメインに分割できる
困難は分割せよ(サブドメイン分割)
サブドメインで発生するドメインイベントから、集約の状態遷移を型で構造化できる
状態遷移をCommand化して、実行とイベントはランタイムに任せる
「型と型を組み合わせた構造化」がよりよくできればプログラムが堅牢になる
型で構造化できると、状態遷移表などによって設計を可視化できる
ドメインモデルの内部には、永続化にまつわる情報を混入させるべきではない
モデルのアイデンティティが変化していく時間と空間はImmutable Modelで表現する
状態管理ではなく関係と関連に着目した状態法則を考える
ロバストネス分析
EventStorming
#Domain_Modeling_Made_Functional
#DIKWピラミッド
#OODA