DDD Starter Modelling Process
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/ddd-starter-modelling-process.jpg
1. 整合させる
アーキテクチャ、コード、組織に関するすべての意思決定は、業務とユーザに何らかの影響を与える。ソフトウェアシステムを最も効果的に設計・構築し、進化させていくには、最適なビジネスインパクトを生み出す必要がある。
業務の観点からはビジネスモデルキャンバスを、ユーザの観点からはユーザストーリーマッピングを、取っ掛かりとして書くとよいだろう。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/business-model-canvas.png
2. 見つける
視覚的に、協調的にドメインを見つけ出す。
これはDDDの最も重要な側面であり、この「見つける」行為をスキップすることはできない。チーム全体でドメインについての理解を深めなければ、すべてのソフトウェアの意思決定は誤ったものになる。
チーム全体にドメインの知識を広めることで、共通の理解が生まれる。将来のビジネスの変化にも柔軟に対応できるように、ドメインに沿ったソフトウェアシステムを、開発者は構築できるようになるだろう。
ドメイン知識がチーム全体に行き渡るようにして、メンバーは製品を改善するためのアイデアを出し合ってビジネス貢献が出来るようになる。
EventStormingを手始めにやるのがよいだろう。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/event_storming.jpeg
3. 分解する
ドメインをサブドメインに分解する。
大きな問題領域を、いくつかの主要な理由からサブドメインに分解する。
認知負荷を減らし、ドメインの一部を他に依存せずに理解できるようにする
開発チームに自律性を与えて、個々で作業できるようにする
疎結合と高凝集を保ち、アーキテクチャやチーム構造に反映させる
EventStormingをもとに、サブドメインとコンテキストマップを作ってみるとよいだろう。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/event_storm_sub_domains.png
4. つなぐ
各サブドメインを、エンドトゥエンドの業務のユースケースを満たす疎結合アーキテクチャに接続する。
大きなドメインをパーツに分解するだけでなく、それらのパーツ間の相互作用を慎重に設計し、不要な結合と複雑さを最小限に抑えることが必要不可欠だ。隠された複雑さを明らかにするために、具体的なユースケースを適用して初期設計をしよう。
取っ掛かりとして、ドメインメッセージフローモデリングを書いてみるとよいだろう。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/domain-message-flow.jpg
5. 戦略化する
サブドメインを戦略的にマッピングして、コアドメインを特定する。
時間とリソースは有限なので、ドメインのどの部分に集中するか理解することが、最適なビジネスインパクトを実現するためにとても重要だ。
自分たちのコアドメインが何であるかを分析し、システムの各パーツにどの程度の品質と厳格さがあるかをよく知った上で、自作するのか、買ってくるのか、外注するのかを意思決定できるようになる。
このためには、コアドメイン図を書くとよい。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/core-domain-chart.jpg
6. 組織化する
コンテキストの境界にしたがい自律的なチームを編成する。
チームは自律性、明確な目標、目的意識をもって編成される必要がある。そのため、組織的な制約を考慮し、ファストフローを生み出せるチーム編成を行う。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/context-map-cheat-sheet.png
7. 定義する
それぞれの境界づけられたコンテキストの役割と責務を定義する。
設計に入る前に、全体に大きな影響を与える可能性のある選択について、明確な決定をしておこう。気持ちを切り替えたり、代替モデルを検討したりするのが簡単なうちに、早い段階でこのような会話をしておく。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/bounded-context-canvas-v4.jpeg
Miroテンプレート
8. コードにおとす
ドメインモデルをコードで書き起こす。
コードをドメインに整合させれば、ドメインが変わったときもコードを変更しやすくなる。問題領域をエキスパートとともにモデリングすると、開発者はドメインについて学ぶよい機会になり、思い違いを最小限に抑えることができる。
手始めに集約設計キャンバスを書いてみよう。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/aggregate-design-canvas-v1.jpg