ドメインエキスパートは誰だ！
Evans本を読んでいるとドメインエキスパートという言葉が突然でてきます。
読み進めてみると、ドメインエキスパートｘ開発者＝チームとされ、開発者とは明確に役割が違うようです。
Evans本ではドメインエキスパートの説明を以下のようにしています。
自分の知っていることを蒸留して本質を抽出するように強いられることによって、しばしば自分の理解を精緻にし、ソフトウェアプロジェクトが必要とする概念を理解するようになる。
Evans本（15ページより抜粋）
では一体ドメインエキスパートはプロジェクトに関わる人の誰に当たるのか？
今扱っている業務について誰よりも知っている人
IDDDではこんな感じで説明されています。
役職の名前じゃない。業務の流れについてよくわかっている人がいれば、その人をドメインエキスパートとすればいい。
IDDD(3ページより抜粋）
業務知識に長けた人、プロダクトを設計した人、営業担当・・・少なくても自身よりはよく知っている人を探せばいい。としています。
これはわかりやすいですね。自分自身より知っている人は誰か！探すことがDDDの第一歩。
ドメインエキスパートとの話し方
ドメインエキスパートとどう話していけばいいか。Evans本やIDDD本にいいヒントがあります。
1. ドメインエキスパートも自分の業務を知り尽くしているわけではない。
ドメインエキスパートから学ぶことはもちろん多いが、ドメインエキスパートが開発者から学ぶことも大いにある。チームで（ドメインエキスパートｘ開発者）学び成長いくことでソフトウェアで必要な概念を理解していくということでしょう。ドメインエキスパートだけでも、開発者だけでもソフトウェアは作れない。
2. リードは開発者がする
ドメイン駆動設計は設計とソースコードが一体化しています。だから必要な知識の噛み砕きは開発者がリードして会話していくことが多いでしょう。
また、ドメインエキスパートは業務に必要な知識を有していますが、プロジェクトに必要な知識以上に知っています。開発者がリードしてプロジェクトに必要な知識を蒸留していきましょう。
さいごに
実際どうですかね。ドメインエキスパートもチームメンバーということは、ずっと一緒に会話していく必要があるということですよね。
プロジェクト初期に要件を聞いて設計、実装していくスタイルだとこの方法はあまりうまく行かないでしょう。
こういう学びはプロジェクト初期だけでなく、プロジェクトを通してしていくものだからです。
ずっと、一緒にプロダクトを通してプロダクトとともに成長していく。そういう意味で顧客でも発注者でもないドメインエキスパートという役割があるのだと思います。