難しいコトは言わない！ドメインモデリングのノウハウ集


株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『[LITALICO Engineers Advent Calendar 2020](https://qiita.com/advent-calendar/2020/litalico)』の23日目の記事になります。

障害者福祉分野でエンジニアリングを使って教育領域、働き方領域をよくするために、奮闘しております。


# はじめに

本投稿は、モデリングって難しいとか思っている方ための難しい事を言わないモデリングノウハウの投稿です。
以下の方を対象としています。

* ドメインモデリングに入門したい方
* とりあえず、ドメインモデリングやってみたい方
* ドメイン駆動設計とかやってみたけど、ドメイン要素の抽出が苦手でドメイン貧血症に陥りがちの方
* ドメインエキスパートのコミュニケーション方法に迷いがある。

# ドメイン駆動設計の原則

『エリック・エヴァンスのドメイン駆動設計』の日本語版への序文で以下の原則が記述されています。ドメインモデリングは、ドメイン駆動を駆動させるための中心的な工程であり、そのもであると考えます。

```
・ コアドメインに集中すること。
・ ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること。
・ 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること。
```
DXという言葉が叫ばれ、これまでのIT企業、Web企業だけではなく、リアルドメイン領域をもった事業会社がエンジニアリングを使って事業価値を上げていく事を進める時代にまさに必要な考え方です。ドメインエキスパートは、IT系のディレクションをする方でも、プロダクトオーナーでもありません。専門知識、専門的な業務をもった方々と共同作業をしてモデルを育てる。そういうチャレンジであります。


# ドメインモデリングをはじめる

ドメイン駆動設計を行っている方がも多いのかなっと思っていたりしています。オニオンアーキテクチャ、ヘキサゴンアーキテクチャだ、レイアードアーキテクチャに関する事は様々な方々が書いている書籍等を見てもらうとよいと思います。本投稿は、ドメインモデリングの事を中心に簡単に試せる内容を書いていきます。

というのも、ドメイン駆動設計で開発を進めたいと、いざ初めて見ると、覚える事が多くてかなりのハードルの高さを感じると思います。有用性を体感するのにすごくパワーが必要になります。モデルからコードに落とす話は書籍等で多く語られていますがドメインモデリングの話はなかなかの情報の少なさです。

モデリングをする時によくオススメされる方法論として、RDRA（リレーションシップ駆動要件分析）とかユースケース駆動開発などを実践しドメインモデルを作成していくというものがあります。オブジェクト指向覚えて、UML覚えて、、分析手法を覚えて、、いつコードをかけるのやらと思うコトでしょうorz。

XTechをやろうとしている事業会社に所属しているエンジニアの場合、そもそもドメイン領域のユビキタス言語や業務知識もベースにあるので、重量級の要件分析は冗長な気がしています。なので難しいコトはしないで簡単にドメイン分析ができるコトが求められていると思ってます。

使う図を最小に絞って簡単にドメインモデルを作っていきます。
本投稿では、業務フロー図（アクティビティ図）、ユースケース図、ドメインモデル図を使います。

# Step1.ヒアリング
まず、最初のステップはドメインエキスパートとのコミュニケーションをするコトです。これができない場合、ドメイン駆動設計は難しい状況となります。よいモデル、よいコードとはドメインエキスパートとの会話からはじまります。エンジニアが身近にいない領域の方がにとっては、エンジニアは未知の生物です。アイスブレイクをしつつ話しやすい雰囲気を作りましょう。
![ヒアリング-ヒアリング.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/677a9389-5674-f74d-8d81-89242536516f.jpeg)

#### 必要性
* ドメインエキスパートと一緒にモデルをつくると問題領域への正しいアプローチに近づきます。
* コアドメインの見極めができます。
* 1番の関心事知ることができます。
* ユビキタス言語の候補を知る事ができます。

# Step2.業務フロー (アクティビティ図）
ヒアリングした内容を業務フローにまとめます。以下は、UMLのアクティビティ図を使った業務フローです。エンジニアはユースケース図、クラス図などモデルはいくつか書くと思いますが、、残念ながら、ドメインエキスパートは、どのモデル図も見てくれません。なにか呪いの儀式かなにかと思われてしまいます。そこでドメインエキスパートとの共通のコミュニケーション手段としてのモデルは業務フローがいいと思います。ドメインエキスパートの方が作るのは難しいかもしれませんが、業務フローは共通のモデルとして機能する事が可能です。業務を見学させてもらうなり、ヒアリングなりして完成させましょう。ホワイトボードで一緒に書くのもよいと思います。

![ショッピング.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/d88b8f4d-e083-e26c-eaba-8ed04d4c0f65.jpeg)

いくつかの工夫をしています。業務フローの中に[いらすとや](https://www.irasutoya.com/)の画像を差し込みしています。いくつかのアクティビティの集合がコンテキストになりえます。それがわかりやすいようにイメージとあった画像をいらすとやさんで探して差し込みしておきます。ドメインエキスパートの方も文字ばっかりのアクティビティ図より、この方がイメージを持ってもらいやすくコミュニケーションが進みます。エンジニアも抽象化されたコンテキストを発見できますので一石二鳥です。

#### 必要性
* ドメイン知識の可視化
* 境界づけられたコンテキストの発見
* ユビキタス言語の発見


# Step3.ユースケース
みんな大好きなユースケース図です。このフェーズを深堀りするとユースケース駆動開発になりますので、、、シンプルにここでは業務フローからユースケースを抽出してユースケース図を作成します。たぶん、この段階でロバネスト分析できちゃう人は、本投稿の対象者じゃない気もします!^^ ロバネスト図を使ってドメインモデルを作っていく事もいいと思いますし、ユースケース記述を作ってドメインモデルに落としていくもいいのですが、、そのフェーズは次のドメイン分解表に譲ってます。このフェーズではシステム化領域を判断するためにユースケースを作成しシステム化するべき所を考察します。

![ショッピング_UC.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/b71d6e05-8b79-be78-6c90-2e9b705d9cdc.jpeg)

#### 必要性
* システム化のスコープを可視化する
* ユースケースとユースケースの関係を可視化する。


# Step4.ドメイン分解表（Original）
ドメインオブジェクトを見つけます。また、ドメインエキスパートからルールや制約を聞き出すのに表であると共通理解になりやすいという意図があります。

![ドメインモデリング - Google スプレッドシート 2020-12-23 02-52-14.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/90e00468-3938-9f16-b30c-659085e4e29d.jpeg)
S:主語、V：動詞、O:目的語、C：補語。 この４つの構文要素を使ってストーリーを分解します。これは良い文章で表現する事ができるとドメインエキスパートとのコミュニケーションんも円滑にでる事もありますが、分解しやすさが主な理由です。 

[現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/B073GSDBGT/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1) で書かているヒト、モノ、コトで分類します。

分類| 例
---|---
ヒト| 個人、企業、担当者、など
モノ| 商品、サービス、店舗、場所、権利、義務、など
コト| 予約、注文、支払、出荷、キャンセル、など

S:主語はヒトになります。O:目的語はドメインオブジェクト候補です。V：動詞はコトとして分類します。C:補語は主語あるいは目的語を補う語ですが、ビジネスルールになる可能性があります。シナリオはドメインエキスパートと共通認識ができている状態のものを分解する事が大切です。分解して分類するここがなかなかドメインモデリングの難しい所なのだと思います。

この表は、ドメインモデル図とコードの密度をあげたい想いが強い人はノイズであると思われるかもしれませんが、頭の中で同じような分解は行っていると想います。ドメインエキスパートはクラス図も、コードも見れないのでコミュニケーションの補完として活用します。

#### 必要性
* ルール・制約の可視化
* 使い捨てでいいと思うけども、、コードで書いてもドメインエキスパートと共有認識を持つのは難しい。
* ドメインイベントの発見


# Step4 ドメインモデル図
準備体操が長くなりましたが、ここでクラス図です。前フェーズでヒト・モノ・コトに分類できるたと思います。あとはこれを組み合わせてクラス図を書いていきます。

ポイントはヒト・モノとコトは関連があります。
ヒト・モノがコトを実行するとモノと関連するという流れが作れれば漏れがないドメインモデルになっていると思います。
![コトモノ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/4290f9d2-eb7c-d8b9-b6dc-a035d5f19102.jpeg)
モノとモノの関連は集約だったりすることが多かったりします。 ここでユビキタス言語を登場させるのもいいでしょう。 『商品』と『購入商品』はユビキタス言語を意識してます。ここでは記述してませんが、『ビニール袋』はきっと『購入済み商品』を持っていると表現できるのです。

![ショッピング_クラス図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51607/4dce4494-9754-cf06-2328-7f9850274a17.jpeg)
※ 雑でごめんなさい

#### 必要性
* モノ・コトが表現されている
* 課題領域の可視化
* 集約の可視化


# まとめ
ある程度ドメインモデルができたらコードに落とすといいと思います。

ドメインモデルとコードで繰り返し変更を加えると、よりよいモデルができると思います。情報可視化術としてのドメインモデルは非常にわかりやすいと思うのですが、、、なかなかエンジニア以外の方に見せても難しいところです。

ドメインモデルを書くのがゴールではありません。

コアドメインに集中するために、ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルをよくするという事がドメイン駆動の大切なところであります。業務フローやスプレッドシート使って共同作業してもいいじゃないかというように思ってます。


# 最後に
障害者福祉の分野は、複雑な業務の塊なような所です。
モデリング大好きな自分にとっては、なかなかチャレンジング環境であります。

現在、LITALICOではデザイナーやエンジニアを絶賛採用募集中です。ぜひご気軽に、お話だけでも聞きに来てください。

明日は、@kamesennin さんです。お楽しみにです。
『[LITALICO Engineers Advent Calendar 2020](https://qiita.com/advent-calendar/2020/litalico)』