エンジニアの谷井です。IMDLではドメイン駆動設計を取り入れています。今回はどのようにドメイン駆動設計を使って開発を進めているのかご紹介します。

ドメイン駆動設計 (DDD) とは

ドメインとは、システムが対象とするビジネス領域のことです。例えば「コンサートのチケット予約」というドメインがあるとすると、その中には会員、コンサート情報、予約、支払い、チケット発行、会場受付などの概念が含まれ、それぞれに業務や相互の関係があります。

システムは現実に存在する問題を解決する必要があります。たとえば、チケットの価格を決めるために複雑なルールがあるならば、それを保守しやすく作ることは重要です。しかし、時としてエンジニアは技術的な問題、例えばチケット予約の性能やデータ整合性を重視しがちです。

ドメイン駆動設計（Domain-Driven Design）では、システム設計において、ドメインそのものとドメインのロジックに焦点をあてます。これによって現実のドメインに変更があった場合、その変更をシステムに反映することが容易になります。

前述のチケットの価格決定であれば、その決定要因として会員種別なのか、コンサートの種類なのか、あるいはコンサートまでの期間なのか、どういった考え方なのかを正確に把握する必要があります。この概念に従ったプログラムを組んでおけば、会員種別が増える、コンサートの種類が増える、といった変更に対して、安心してシステムを変更することができます。

三越伊勢丹におけるドメイン

IMDLは三越伊勢丹の店頭においてスタイリスト（販売員）がお客さまに提供してきたサービスをデジタル化しています。つまり、IMDLが主に扱うドメインは「三越伊勢丹における接客や販売」です。

私のチームでは、お客さま向けの三越伊勢丹リモートショッピングアプリと、その裏側でスタイリストが使う接客支援ツールというサービスを開発しています。以下では、これらを「リモショアプリ」と呼びます。

リモショアプリが対象としているドメインには以下のような概念が含まれます。
- 会員
- 店舗、お買場
- 接客ルーム
- カート
- 予約

それぞれの概念について簡単にご紹介します。

1. 会員
会員とはお客さまのことですが、ここでは特に「三越伊勢丹デジタル会員」のことを意味します。会員になるとお客さまの氏名やメールアドレスなどを保管します。

この概念におけるユースケース（活用事例）としては、会員登録、会員情報の変更や取得などが挙げられます。

2. 店舗、お買場
これは現実の店舗、そしてお買場をデジタルに置き換えた概念になります。例えば、新宿伊勢丹本館1階のジュエリー売り場、などです。

ユースケースとしては、ウェルカムメッセージ（フレンド登録時に送られるメッセージ）を送る、自動返信をする、などがあります。

3. 接客ルーム
リモショアプリでは、ショップ毎にお客さまの情報を管理しています。その情報の枠となるのがこの「接客ルーム」です。お客さまはリモショアプリを使ってスタイリストとチャットをすることができますが、そのチャットもこの接客ルームに含まれます。

ユースケースとしては、ルーム作成（分かりやすく言えば「フレンド登録」）、メッセージ送信、未読件数取得などが挙げられます。

4. カート
お客さまがリモショアプリを通してお買い物をされる際、スタイリストはお客さまが注文された商品をカートに追加して、そのお客さまのショッピングカートをご決済待ちとして登録します。

ユースケースとしては、商品追加、カート登録、決済などが挙げられます。

5. 予約
リモショアプリにおける予約とは、ビデオ接客の予約のことを指します。お客さまはリモショアプリを通じてビデオ接客を予約し、お買場のスタイリストからビデオ通話で商品の紹介を受けることができます。
この裏側には予約サービスというリモショアプリとはまた別のシステムがあるのですが、ここでは説明を割愛します。

ビデオ接客予約のユースケースとしては、予約する、予約をキャンセルする、などが挙げられます。

DDDの進め方

まず開発する案件に対して、メンバー全員でドメインモデリングをします。具体的には、シーケンス図やUIフロー図、ユースケース図などを作成し、ドメインを図式化して理解しやすい形に落とし込むことを目指します。

ドメインモデリングでは、ドメインの問題を解決するためのモデル（型）を設計します。ドメインモデルの認識がズレると正しく問題が解決できなくなるので、開発メンバー全員で行っています。その次に行うのがデータモデリングです。これは、ドメインモデリングの結果をデータ構造に反映させ、永続化させるための作業です。この際にデータモデル図を作成します。

これらのモデリングが完了すると、ドメイン層の実装を行います。ここでコアとなるビジネスロジックの実装を完了させ、その後にUIなどを実装していきます。

ドメインモデリングを正しく行うためには、POからのドメインに関する説明が重要です。IMDLではスクラム開発を行っているため、プロダクトバックログリファインメントやスプリントプランニングなどで説明がおこなわれます。その場での理解が浅いとドメイン層に後から修正が入るなどの問題が発生します。

例えば、こんな問題がありました。接客支援ツールでは、お買場の特性によって画面表示を出し分けています。これを「利用パターン」という概念で制御を行っていました。最初、この利用パターンは、接客ルームとお買場に紐付けられていました。しかし、後に接客ルームへの紐付けが不要であることがわかりました。というのも、開発を進めていく中で、利用パターンは会員の状態に影響を受けることがわかったためです。

この変更はデータ構造にも影響があったため、対応にはそれなりの工数がかかりました。これはドメインモデリングでPOの意図を組み取れきれていなかったことが原因です。こうした失敗を通じて、ドメインモデリングがいかに重要であるか、また、打ち合わせの場ではしつこいぐらいにPOの意図を確認していくことべきだと実感しました。

リモートワークでの実践

ドメインモデリングはホワイトボードを使うと便利ですが、現在は全員はリモートワークが中心になるため、ビデオ通話しながらオンラインのツール使って作業を行っています。実際に集まってドメインモデリングをしたこともありますが、リモートワークでも特に問題はないと感じています。

むしろ、オンラインであればモデル図が残しやすいのでメリットもあります。現状はMiroを中心に使っていますが、他のツールも試してみて、よりよい環境にしていきたいです。

まとめ

今回はリモショアプリを例にIMDLでドメイン駆動設計にどう取り組んでいるのかを紹介しました。

システム開発では先を見越して設計をすることが重要です。しかし、事前に全てを見通すことは極めて困難です。ドメイン駆動設計であれば、現時点での見通しを土台に、変化が発生した場合の差分を明確に理解できるようになることで、システムへの修正に安心して取り組むことができます。こう言った特性がアジャイル開発と相性が良いと感じています。