SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

IDDD本から理解するドメイン駆動設計

ドメイン駆動設計のメリットと始め方 ~ 1章「DDDへの誘い」

IDDD本から理解するドメイン駆動設計 第1回


  • X ポスト
  • このエントリーをはてなブックマークに追加

[HOW1]DDDでユビキタス言語で設計する方法

 続けて、DDDの設計方法について紹介していきます。まず最初に、DDDで最も重要な概念とも言える「ユビキタス言語」について紹介します。

ユビキタス言語

 「ユビキタス言語」とはドメインエキスパートや開発者を含めたチーム全体で作り上げる共有言語のことです。同じ用語を使って話すという表面的なものではなく、日本語という自然言語を元にした「チーム全体で作り上げる特別な共有言語」で、DSL(ドメイン固有言語)の一種ともいえます。例えば「商品」や「在庫」という言葉ひとつをとっても、それは「境界づけられたコンテキスト(2章で解説)」ごとに違うニュアンスと振る舞いを持ちます。ユビキタス言語は、そのままコードとして実装されるため、注意深く検討する必要があります。

ユビキタス言語の見つけ方

 プロジェクト開始時は、次の方法でユビキタス言語を探すことができます。

  1. ドメインに登場する用語について名称とアクションを記載する(正式なUMLにこだわると議論が進まなくなるのでフリーフォーマットで記載する)。
  2. ユビキタス言語選定のために「用語集」を作成する。用語の候補と採用/却下理由を記載する。さらに用語の定義を書くことで、ドメインに関連する用語を見つけられる。
  3. 用語集の作成が困難な場合は、すでに存在しているドキュメントを集めてきて、重要な用語やフレーズを取り出す。

 上記作業は一部の人間だけで行ってもかまいませんが、レビューはチーム全体で行います。

ユビキタス言語を見つけた後のステップ

 ユビキタス言語の候補を見つけたら、そのままソースコードに反映します。例えば「顧客」という用語に「姓名を変える」という振る舞いがあれば、そのままドメインモデルとして実装します。顧客クラスに「姓」や「名」というフィールドを公開するだけではなく、「姓名を変える」というメソッドを実装します。

 先ほど作成した図や用語集は、そのうち使用しなくなります。ドキュメントを管理する代わりに「コード内のモデル」と「チーム内での会話」として、ユビキタス言語をメンテナンスし続けます。言い換えれば、ユビキタス言語に含まれない概念はコードにも存在しないことになります。

[HOW2]DDD導入に向けた周りへの説得方法

 DDDを導入するには、上司の理解を得る必要があります。ここでは、その説得方法について紹介します。

DDDがもたらす事業価値

 DDDが流行っているからとか、面白そうだからという理由だけでは、実際のプロジェクトで採用することは困難です。DDDを始めるにあたり、上司を説得する案は以下のとおりです。

DDDがもたらす事業価値(上から順に価値が高い)
番号 区分 内容
1 ビジネス的価値 組織としてコアドメインに注力し、有益なモデル(コード)を作成できる
2 事業と業務を正しく理解し、定義できる
3 ドメインエキスパートがソフトウェアを設計できる
4 よりよいユーザー体験を提供できる
5 技術的価値 モデル間の境界を明確に定められる
6 エンタープライズアーキテクチャを整理できる
7 アジャイルでイテレーティブなモデリングを継続的に行える
8 新しいツール(戦略:ユビキタス言語、戦術:エンティティ等)を使える

 上司を説得するためには、これらのDDDがもたらす価値を説明することが良いとされています。上記の表の番号が小さいものほどビジネス価値が高くなります。

DDD導入を阻害するもの

 仮に上司を説得できDDDを導入できそうになっても、別の課題があります。一般的に大きく次の3つが障壁となります。

DDD導入に当たっての障害と対策案
番号 課題 対策案
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原則(エヴァンス本より)
  1. コアドメインに集中すること
  2. ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること
  3. 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること

 DDDで重要なことは、ビジネス的に成功しているソフトウェアを構築することです。そのために競争力を持つべきドメインである「コアドメイン」に集中します。そのために、顧客と開発者が一丸となって業務内容とその問題について議論しモデルを検討します。そして、チームの共通言語「ユビキタス言語」を用いたソフトウェアとして構築します。

 開発が進むにつれてDDDの技術的な側面に集中しまうことがあるかもしれませんが、DDDの本質を見失わないようこれらの原則を意識しておくことは重要です。

最後に

 初回となる今回は、DDDの概要と関連情報を紹介しました。そして、IDDD本の1章「DDDの誘い」に従い、DDDを導入する人、理由、メリット、導入方法について紹介しました。

 次回2章「ドメイン、サブドメイン、境界づけられたコンテキスト」では、戦略的設計において重要な概念である、ドメインとコンテキストについて紹介します。

参考資料

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
IDDD本から理解するドメイン駆動設計連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 青木 淳夫(アオキ アツオ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS X: @WingsPro_info(公式)、@WingsPro_info/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9546 2018/11/21 14:13

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング