Domain Modeling Made Functional / 関数型ドメインモデリングドメイン駆動設計と F#でソフトウェアの複雑さに立ち向かおう

1. Introducing Domain-Driven Design

DDD の最終ゴールは、全ての関係者が同一のメンタルモデルを使って話をすること。これにより、早く価値を届け、高い価値を生み、無駄をなくし、保守と拡張を容易にすることができる。

やるべきことは 4 つ。

ビジネスは、ある一時点のデータだけでは表現できないし価値も持たない。

ビジネスは、データを別のデータに変換していく一連のワークフローにより表現され、そこにこそ値があるといえる。

この変換を引き起こすきっかけをドメインイベントと呼ぶ。ドメインイベントは常に「〜が起こった」のような過去形で表現される。

例：

ドメインイベントの発見にはイベントストーミングという手法が有効である。イベントストーミングは以下を目的とする。

イベントを洗い出すときには、少ない範囲で満足せず、可能な限り端まで拡張して見つけ出すことを心がける。

イベントを引き起こす要因をコマンドと呼ぶ。コマンドは常に命令形で表現される。コマンドはワークフローを通じて別のイベントを引き起こす。

全てのイベントがコマンドから発生するわけではなく、スケジュールされたイベントや外部システムからの通知によるものもある。

ドメインとは「密接に関連する知識の範囲」である。

もっとざっくりいうと、ドメインとは専門家が存在する分野のこと。その専門家が実際に行っている仕事の範囲がドメインである。

例えば「請求」というドメインについて考えるなら、請求部門の人たちがやっている仕事の範囲がドメインである。

現実世界のドメインは、互いにほんの少しだけ重複するベン図として表現できる。

現実世界のドメインをソリューションの世界に持ち込むとき、ドメインはBounded Contextsとして扱う。

なぜコンテキストかというと、コンテキストから切り離された情報は混乱を招いたり役に立たなかったりするからである。

なぜ境界を作るかというと、相互依存を排して保守性を高めるためである。

現実世界とソリューションの世界のドメインは必ず 1 対 1 で結びつくわけではない。 1 対多になることもあれば、多対 1 になることもある。

Bounded Contextを正しく作るのは科学ではなくアートの世界だが、いくつかの基準はある。