[HOW1]DDDでユビキタス言語で設計する方法
続けて、DDDの設計方法について紹介していきます。まず最初に、DDDで最も重要な概念とも言える「ユビキタス言語」について紹介します。
ユビキタス言語
「ユビキタス言語」とはドメインエキスパートや開発者を含めたチーム全体で作り上げる共有言語のことです。同じ用語を使って話すという表面的なものではなく、日本語という自然言語を元にした「チーム全体で作り上げる特別な共有言語」で、DSL(ドメイン固有言語)の一種ともいえます。例えば「商品」や「在庫」という言葉ひとつをとっても、それは「境界づけられたコンテキスト(2章で解説)」ごとに違うニュアンスと振る舞いを持ちます。ユビキタス言語は、そのままコードとして実装されるため、注意深く検討する必要があります。
ユビキタス言語の見つけ方
プロジェクト開始時は、次の方法でユビキタス言語を探すことができます。
- ドメインに登場する用語について名称とアクションを記載する(正式なUMLにこだわると議論が進まなくなるのでフリーフォーマットで記載する)。
- ユビキタス言語選定のために「用語集」を作成する。用語の候補と採用/却下理由を記載する。さらに用語の定義を書くことで、ドメインに関連する用語を見つけられる。
- 用語集の作成が困難な場合は、すでに存在しているドキュメントを集めてきて、重要な用語やフレーズを取り出す。
上記作業は一部の人間だけで行ってもかまいませんが、レビューはチーム全体で行います。
ユビキタス言語を見つけた後のステップ
ユビキタス言語の候補を見つけたら、そのままソースコードに反映します。例えば「顧客」という用語に「姓名を変える」という振る舞いがあれば、そのままドメインモデルとして実装します。顧客クラスに「姓」や「名」というフィールドを公開するだけではなく、「姓名を変える」というメソッドを実装します。
先ほど作成した図や用語集は、そのうち使用しなくなります。ドキュメントを管理する代わりに「コード内のモデル」と「チーム内での会話」として、ユビキタス言語をメンテナンスし続けます。言い換えれば、ユビキタス言語に含まれない概念はコードにも存在しないことになります。
[HOW2]DDD導入に向けた周りへの説得方法
DDDを導入するには、上司の理解を得る必要があります。ここでは、その説得方法について紹介します。
DDDがもたらす事業価値
DDDが流行っているからとか、面白そうだからという理由だけでは、実際のプロジェクトで採用することは困難です。DDDを始めるにあたり、上司を説得する案は以下のとおりです。
番号 | 区分 | 内容 |
---|---|---|
1 | ビジネス的価値 | 組織としてコアドメインに注力し、有益なモデル(コード)を作成できる |
2 | 事業と業務を正しく理解し、定義できる | |
3 | ドメインエキスパートがソフトウェアを設計できる | |
4 | よりよいユーザー体験を提供できる | |
5 | 技術的価値 | モデル間の境界を明確に定められる |
6 | エンタープライズアーキテクチャを整理できる | |
7 | アジャイルでイテレーティブなモデリングを継続的に行える | |
8 | 新しいツール(戦略:ユビキタス言語、戦術:エンティティ等)を使える |
上司を説得するためには、これらのDDDがもたらす価値を説明することが良いとされています。上記の表の番号が小さいものほどビジネス価値が高くなります。
DDD導入を阻害するもの
仮に上司を説得できDDDを導入できそうになっても、別の課題があります。一般的に大きく次の3つが障壁となります。
番号 | 課題 | 対策案 |
---|---|---|
1 | 増える作業時間 | 価値を生み出すためには、新たな検討時間が増えることは必須と割り切る |
2 | 多忙なドメインエキスパート | お菓子や飲み物のプレゼントや趣味の雑談をきっかけにしつつ、彼らが興味を持つユビキタス用語で関心を誘う |
3 | 開発者の抵抗 | 技術的視点から業務的視点に関心を移す。それをオブジェクト指向設計で実装できるメリットを理解してもらう |
これらの課題においては、関係者となるキーマンと対話を行い、対策案を通してDDD導入への理解をしてもらう必要があります。
[HOW3]DDD導入に向けた優先順位/体制
最後に上司や関係者の説得が終わり、導入できることになった場合の優先順位や体制について紹介します。
ドメインモデリングの導入体制
DDDで開発する場合、「ドメインモデル」を構築する「ドメインモデリング」を行う必要があります。ドメインモデリングをスムーズに導入するための優先順位と取り組み方について下表にて紹介します。
優先順位 | 優先順に沿った取り組み方 |
---|---|
1 | ドメインで一番重要な「コアドメイン」にエースエンジニアを投入し、戦術的設計を行う |
2 | コアドメイン以外で重要な「汎用サブドメイン」においても戦術的設計の検討を行う |
3 | 重要ではない「支援サブドメイン」では、状況に応じて判断する |
基本的には、注力するべきDDDの領域に優秀な要員が配員できるように留意して、ドメインモデリングを適切に行うようにします。DDDの導入にはこれまで発生しなかった実装コストや教育コストがかかりますので、優先順位が高いドメインに注力し、それ以外ではDDDを採用するか状況に応じて検討すると良いでしょう。
アジャイルを前提としたDDD
なお、DDDはアジャイル開発を前提としています。そのため、アジャイル開発の経験があるメンバーのほうがDDD導入がスムーズになる可能性があります。
また、DDDでは設計段階から、アジャイルの概念における「テストファースト」でモデルを検討することが可能です。例えば、新しいモデルの概念がドメインに出てきた場合、以下の流れで開発を行います。
順番 | 検討内容 |
---|---|
1 | ドメインで必要とされるモデルについて、チーム全体で検討する |
2 | どのように使用するかについて、チーム全体で考える |
3 | 開発者は、テストコードを書く |
4 | 開発者は、ドメインモデルのコーディングを行う |
5 | 開発者は、リファクタリングを行す |
6 | ドメインエキスパートは、テストコードを見て、ユビキタス言語の認識が正しいかを確認する |
これは従来のTDDのテストファーストの考え方と同様ですが、モデルの使われ方をドメインエキスパートとともに設計時点から検証できる点でメリットがあります。
エヴァンスによる「DDDの原則」
エヴァンスは日本語翻訳版の序文にて「DDDの原則」は次の3つと述べています。
DDDの3原則(エヴァンス本より)
- コアドメインに集中すること
- ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること
- 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること
DDDで重要なことは、ビジネス的に成功しているソフトウェアを構築することです。そのために競争力を持つべきドメインである「コアドメイン」に集中します。そのために、顧客と開発者が一丸となって業務内容とその問題について議論しモデルを検討します。そして、チームの共通言語「ユビキタス言語」を用いたソフトウェアとして構築します。
開発が進むにつれてDDDの技術的な側面に集中しまうことがあるかもしれませんが、DDDの本質を見失わないようこれらの原則を意識しておくことは重要です。
最後に
初回となる今回は、DDDの概要と関連情報を紹介しました。そして、IDDD本の1章「DDDの誘い」に従い、DDDを導入する人、理由、メリット、導入方法について紹介しました。
次回2章「ドメイン、サブドメイン、境界づけられたコンテキスト」では、戦略的設計において重要な概念である、ドメインとコンテキストについて紹介します。
参考資料
- Domain-Driven Designのエッセンス(オブジェクトの広場)
- Domain Driven Design(ドメイン駆動設計) Quickly 日本語版(InfoQ)
- 実践ドメイン駆動設計の用語まとめ(qiita)
- ユビキタス言語(Martin Fowler's Bliki (ja))
- DDD ユビキタス言語再考(Speaker Deck)
- ユビキタス言語 どこでも業務の言葉(システム設計日記)
- ユビキタス言語とドメイン名の決め方(Septeni Engineer's Blog)
- ユビキタス言語のベースの言語(yasuabe blog)
- ドメイン駆動設計のためのオブジェクト指向入門(SlideShare)
- ドメイン駆動設計をかじってみる(TECHSCORE BLOG)
- ドメイン駆動開発(Wikipedia)