DDDとRDRAを組み合わせて使うには
かとじゅん様（@j5ik2o）
感想
DDDを実践しようと思ったらRDRAの外側のレイヤーに注目する考え方が有用で、業務を理解しないことには適切なドメインモデルが導かれないというお話でした。
DDDとRDRAを組み合わせていく上で現場で実践していることをDDDとRDRAの用語の関係ベースで説明されていて、自分の中で対応関係が明確になりました。
DDDの文脈で重要視されている、コアドメインで仕事しているか否かという部分についても境界づけられたコンテキストとシステム価値を対応させることで判断の助けになるなど実務で使える知識を得ることができ勉強になりました。
かとじゅん様、ありがとうございましたm( )m
以下メモ
要求の分析したことを分析したまま実装に落とし込むというDDDの考え方（単一モデル）の元でRDRAを生かしたという観点での発表。
ドメインモデルとは
- 実装を見れば分析の結果がわかる、ビジネスルールがわかるという状態を目指す。
- 例えば、請求クラスは支払い期日に基づいているのでインスタンスを内包する可能性が高い。
いきなりドメインモデルを作れるか
- 初見だとほぼ無理であるためドメインモデルが導かれる元となる外部環境に注目する。
- システム価値を整理することでコアドメインで仕事しているか否かがわかる。
- システム外部環境を整理することでドメインモデルの輪郭が特定できる。その業務が未経験であればあるほど。
ユースケースモデル
- 今回の発表では文章だがRDRAだと図で表す。人間とシステムの対話のシナリオを示していて、（E）はEntity、（C）はコントロール（動詞の部分）、（B）はバウンダリーを表している。
- 用語の候補は操作マニュアル等が参考になる。
システム境界とBCEステレオタイプ
名詞
- バウンダリーはユーザーインターフェースのこと。
- Entityはドメインオブジェクトのこと。
動詞
イベントモデルから分析する
- イベントは他のシステムと連携することがある。
- 業務上で起きるイベントに注目してモデリングする（EventStorming）
ユースケースいきなりかけるか問題
- 業務知らないとユースケースは書けない
→ システム外部環境を知るべき
- 利用シーンを用いて、どのような場面で使われるかや利害関係者を紐づける。
→ 利用シーンや利害関係者がいない機能があったらそれはいらない機能。
→ ユビキタス言語の候補が整理していくと出てくる。
→ ユビキタス言語はこのような分析を行って初めてできるものであり、いきなり降って湧いてくるものではない。
概念モデル
声に出してモデリングのが良い。
→ 自分で言語化するときに違和感を覚えたものはモデリングがおかしい。相手に伝わる表現が大事。
→ どうしても声に出すだけでは伝えるのが難しいものはホワイトボードにインスタントに絵を描いて説明する。ただしホワイトボードに書かないと伝えられないものはシンプルなモデルではないかも。
→ 日常的な会話にモデルが出てこないとおかしい。
コアドメインで仕事しているか
- 汎用サブドメインとは他の代替技術があれば置き換えられるもの。
- 支援サブドメインとはコアほど重要じゃないけど必要不可欠なもの。
- コアドメインとはビジネスの核心であり、システム価値を整理することでコアドメインで仕事しているか否かがわかる。
- インセプションデッキやPRDとシステム価値は同様の事柄が記述されるはず。
コンテキストモデル
- 利害関係者や外部システムとの関係を洗い出す。
- 利害関係者が満足する要件は何か→その要件を満たすドメインモデルって何という感じでRDRAとDDDは直に繋がっている
