ドメイン駆動について考えてみた②　ドメインモデル

第1回目はこちら
前回は、言葉をちゃんと整理して使おうと言うことを書きました。

第2回目は、ドメインモデルについて書きたいと思います。

ドメインモデルの前に・・そもそもシステム開発の目的は何でしょうか？
お客さんに作って欲しいと言われたから？　仕事だから？ お金を稼ぐため？
色々、思いつくかもしれませんが、
私は「何かしらビジネスを行う上での課題を解決する為」の手段だと考えています。

そして、課題となる対象(ターゲット)をドメインと定義します。

例えば・・・
「ホテルビジネスを展開していた場合、もっとお客さんが来ないかなと問題を抱えています。」
「色々調査したところ電話予約しかない為とても予約しにくいという、原因が見つかりました。」
「なので、ホテルは24時間気軽に予約できるようにカイゼンするという課題を設定しました。」

この、課題とする範囲をドメインと定義します。
※問題と課題の違いは、問題=ネガティブ発言、課題=ポジティブ発言と整理しています。

では、このドメインをモデル化してみましょう。

Step１．ドメインエキスパートと会話しよう
この、ドメインについて詳しい人をドメインエキスパートと呼びます。まずは、ドメインエキスパート話している言葉を「よく聞いて」、「よく整理して」ユビキタス言語を抽出しましょう。

ドメインエキスパート：「お客さまが会員の場合は、予約サービスを表示して、ホテル予約ができるようになります。予約可能日は、予約台帳を見て予約が埋まっていない場合は、予約可能となります。」

ユビキタス言語
お客さま：ホテルを利用する人
予約サービス：ホテル予約ができるシステム
会員：システムが利用できるお客さま
予約台帳：ホテルの予約状況が書かれている予約状況を管理しているサービス

Step２．ドメインエキスパートとの会話を元にモデル化しよう

会員では無い時どうするかわかりませんね。質問してみましょう。
ドメインエキスパート：「ホテルポータルサイトがあり、会員はそこから予約サービスが利用できます。」
エンジニア：「ログインはどうやってやるのでしょうか？」
ドメインエキスパート：「ログイン？ メールアドレスとパスワードで、本人かどうかを確認したいです。」
エンジニア：「ポータルサイトには、どのようなものが表示されますか？」
・・・など

Step３．会話を元にドメインモデルを更新しましょう。
エンジニア：「ホテルポータルサイトは、予約サービスと名前をそろえて、ポータルサービスで良いでしょうか？」
ドメインエキスパート：「その方がわかりやすいですね。そうしましょう。」

このように会話をしながら、モデル化を進めていきましょう。
上記図も途中の状態です、例えばおススメ宿泊プランはどこから持ってくるとか、ホテルが持っている部屋数がわからなかったりしています。

次回はレイヤーについて説明します。

今回、クラス図を書くのにdrow.ioを利用しました。
便利でしたので、ご紹介いたします。 →  drow.io