さて、ドメインモデルを作るにはドメインを分析しなければなりません。
ドメインを分析するとは具体的にどうすればいいでしょうか？
もちろんドメインを決定づける Dominus を知らなければなりません。
ではどうやって Dominus を探すのか？
ドメインエキスパートに聞く？
どれが Dominus か分からない…
正しく知るにはどうすればいいのか？
私は幸運にも大学を出ているので
アカデミックな方法を取ります。
アカデミックと言ってもアカデミアを作った
プラトンの方法です。
ソクラテスの「無知の知」です。
プラトンの著書の中で
ソクラテスはこう言いました。
私はこの人間よりは知恵がある。この人は知らないのに知っていると思っているのに対して、私のほうは、知らないので、ちょうどそのとおり、知らないと思っているのだから。どうやら、なにかほんの小さな点で、私はこの人よりも知恵があるようだ。つまり、私は、知らないことを、知らないと思っているという点で。
これは
「私は何も知らないのだから思い込みを捨てて
謙虚な心で知ろうとしなければならない」
という意味
ではありません。
私は本当に何も知らないので、
単に何も知らないという意味でしかないです。
具体的に言うと
ドメインエキスパートと
ドメインの話をしているとして
「自分が何の話をしているか」
も知りません。
だから
何の話をしているか分からなくてもできる質問
をしなければなりません。
それは
映画館って言うのは映画を見るところですか？
映画って何ですか？でも良い。
いや冗談ではなく、
私は映画館に行ったことが無いし、
もう数年もすれば
動画は解るけど映画は分からない
そんな人たちが出てきます。
知っていることと知らない事の境界は、
「自分を含め会話の参加者が
能動的に行動しないでも
経験してないことがあり得るか？」
この記事を読んでいる貴方は
ネット上の記事を読んでいるわけで
映画の情報は受動的に入ってくるはずだし
万一映画は知らなくても
動画は広告などで無理やり見せられているはず
なので動画や音声は知ってることにしてOK。
義務教育でやったことや
普段の生活で避けるのが難しいことも
知っていることでOK。
「世界とは人生とは何か」とか聞く必要はない。
話を戻して
映画館は映画を見るところであり
映画の見れない映画館は映画館ではない。
と答えてもらったとします。
映画の見れない映画館は映画館ではない。
ならば「映画を見る」ことこそがコアです。
コアが無ければそれはもうドメインではない。
「映画を見る」ことがコアならば
「映画を見る人」が Dominus です。
映画を見るか見ないかは
「映画を見る人」が決めるし
「映画を見る人」が存在できない映画館は
映画館ではない何かです。
もう一度、
ドメインエキスパートの話を見てみましょう。
観客いないな！
このように、自分が何も知らないとして
謙虚な心でドメインエキスパートの話を聞いても
コアが欠けていてはそれは
ドメインではなくドーナツです🍩
Wikipediaで映画館の定義を見てみましょう。
「スクリーンに投影された映像を不特定多数の人間が同一の場所で視覚的に共有する」
流石 Wikipedia です。Dominus = 観客がいますね。
他にもスクリーンと映像が出てきました。
スクリーンはきっと部屋に一つでしょう。
部屋には多数の椅子があり一人ずつ座る。
ところでこれは鬼滅の刃の上映予定です。
流石、鬼滅の刃ですね！
何スクリーンも同時に上映しています！
ところでドメインエキスパートの話をもう一度見てみましょうか。
映画タイトルと日時だけではどのスクリーンの座席表なのか分からない…！
それとも全部のスクリーンの座席をずらりと並べてその中から選ぶのか？
このように
Dominus から関連を引いてモデルを作ることで
ドメインエキスパートが知ってると思い込んでる
事が実は分からない、と言うことが解ります。
ところでいつの間にかモデルに映画館が出てますね？
実のところ Dominus は観客だけではありません。
映画館は見せる映画やスクリーンや椅子を規定します。
つまり映画館も Dominus です。
ただ観客に無理やり映画を見せることはできません。
映画館はいわばサブ Dominus です。
映画館には部屋とスクリーンと座席があり、
映画の上映時間の間、観客にそれを提供します。
もう一度、ドメインエキスパートの話を見てみましょう。
誰が座席表を見るのか
その座席表は誰が提供するのかが分からない…
日本人は
「誰が誰に提供するのか」
に無頓着なのでたいてい書き忘れます。
必要とすら思わない、と言っても良いでしょう。
が Dominus が関わってくると話が違います。
Dominus は行動と資源の決定権を握ります。
主権とはそういう事です。
複数いるのならば「誰が誰に」こそ重要です。
英語が「誰」を必要としているのはそういう事です。
まぁ、英語でも映画館が映画を見せるのは
映画館 = Server が 映画 = Service を提供すると
雑に抽象化する人ばかりなのですが
例えば、座席を管理するシステムを作る場合、
100人の開発者がいれば99人は
座席管理 Domain Service
を作ってしまいます。
ちょくちょく Service はドメインに含むか？
という話題が発生しますが
サービス提供者を明示することで
Domain Service なんて不要になります。
というか Service なんてフワッとしたものを
考えるから話がややこしくなるのに。
このように、ドメインに含むべきではないものを
除去することも重要です。
映画館や座席は Repository に永続化されます。
ですがモデルには Repository は出てきません。
Dominus は Repository なんか知らないです。
Repository の話は長くなるし
Dominus と関係ないので要望が有れば
そのうちに書きます。
話を戻しますが実のところ
観客のコアドメインと
映画館のコアドメインは違い、
観客のコアドメインのほうは
ビジネスそのものではなく
システム化されるわけでもないので
無視されがちです。
席とチケットを売るのは
映画館のコアドメインと言って良いでしょう。
ですがそこがスタートではいけません。
最悪の場合では映画も見せずに
席を売るシステムになるかもしれません。
それはドメインではなくドーナツです🍩
何よりも重要なのは Dominus との関連として
モデルを作り上げる事です。
Entity だの Value Object だのは
構成部品でしかないです。
Domain そのものではありません。
Domain Model を作るなら
Domain の話をするべきです。
Dominus との関連を記述するべきです。
貴方は Domain の話ができていますか？
Domain の話をせず Entity や repository の話を
して「DDD やってます！」と言ってませんか？
それは本当に Domain Driven ですか？
Domain に目を向けて Domain Driven で
やっていきましょう！
私の誤解や説明不足が有ったら
コメントしていただけると嬉しいです！
後日何か書けるかもしれません！
ご清聴ありがとうございました。