DDDの手順のざっくりまとめ

DDDに取り組む理由

- プロジェクトメンバーがドメインに関する共通認識をもてる
- 仕様書を書くための材料を揃えられる

単語の定義

シナリオ：オペレーションシナリオ・コンテキストシナリオ・CMJにあたるもの。ユーザーがソフトウェアを使用する際の流れがタスクベースにわかるもの。
ドメイン：知識・影響・活動の範囲を指す。具体的にはプロジェクトの領域など。
ドメインエキスパート：プロジェクトメンバーで、対象ドメインの深い知識を持っている人。
ドメインモデル：ドメインのモデル。情報フロー・ワークフローダイアグラムを含むもの。UMLやテキストで表現され、それらが伝えようとしている概念のこと。
ユビキタス言語：共通言語のこと。プロジェクトメンバー全員が対象について同じ言葉を使う。
ユースケースシナリオ：機能ベースのシナリオ。「ユーザーが、ソフトウェアの何を見て、何のアクションするのか」といった粒度のもの。

1. シナリオを引く・ユビキタス言語を定義する

ドメインエキスパート・ステークホルダーを含むプロジェクトメンバーで一緒にシナリオを引く。抽象的な内容を具体的にする最初のステップなので、プロジェクトメンバーはなるべく参加する。シナリオを引きながら、ユビキタス言語を定義する。

2. ドメインモデルを作る

1 のシナリオからオブジェクトを抽出し、ドメインモデルを作る。アウトプットはUML図か、テキストになる。（他の形もあるかもしれないけど、書籍や記事によると恐らくこの2つ。）
モデル作成時にユビキタス言語を使用し、共通言語集としても使うことができるようにする。
モデルは、1つのチームに割り当てられるくらい小さくするべき。

3. ユースケースシナリオを作る

1 と2 を元にユースケースシナリオを作成する。レビューのプロセスを挟むなどしてプロジェクトメンバー全員を巻き込みながら、完成度を上げていく。ユースケースシナリオを元に、デザイナー・エンジニア・QAがそれぞれ動き出すことができるようになるのが理想的。

4. プロジェクトメンバーがそれぞれ行動する

今までのアウトプットを元に、プロジェクトメンバーがそれぞれ動く。デザイナーは画面を設計し、エンジニアはフロント・バックエンドを作り、QAはテストシナリオを作成する。
動き始めてからも、1 ~ 3 の内容は常に更新する。

エリック・エヴァンスからのアドバイス

以下のドキュメントの最後に、エリック・エヴァンスへのインタビューが書かれている。

https://www.infoq.com/jp/minibooks/domain-driven-design-quickly/

そこにドメインモデリングをする際の注意点の記載があり、とても参考になった。
▼一部抜粋

1) 開発に参加してください。モデリングする人にはコードが必要です。
2) 具体的なシナリオに取り組みましょう。抽象的な考えは具現化しなければなりません。
3) すべてにDDDを適用しようとしないでください。コンテキストマップを描いて、どこにDDDを適用して、どこに適用しないのかを決めましょう。そうすれば、適用外の部分を心配しなくてもよくなります。
4) たくさん実験をしてください。そして多くの失敗を想定してください。モデリングは創造的な作業です。

DDDはあくまでフレーム。ユーザーに届けたい価値を忘れずに開発することを忘れないように、進めていければと思う。