ドメイン駆動設計はどのような開発手法？開発の流れやメリットもご紹介

システム開発において、「我々がベストと思うシステムを提案したのに、受け入れてもらえない」「想定と異なる仕様のシステムが納品された」という経験をした方もいるのではないでしょうか。顧客のニーズに合ったシステムを構築するという観点で、ドメイン駆動設計が注目されています。

この記事ではドメイン駆動設計を詳しく、わかりやすく解説します。「本当に顧客のニーズにマッチするシステムをつくりたい」「ドメイン駆動設計の説明を読んだがわかりにくい」という方は、ぜひお読みください。

ドメイン駆動設計とは

ドメイン駆動設計がどのような開発手法か理解することは重要です。どのような手法なのか、また重要な用語の一つ「ドメイン駆動設計の原則」について確認していきましょう。

業務仕様やナレッジとコードを一体化させる手法

ドメイン駆動設計はエリック・エヴァンス氏により提唱された概念で、DDD（Domain-Driven Design）とも呼ばれています。あるべき業務仕様やビジネス上の約束事を実現する手法をドメインモデルとして、システムの中核に据えます。ドメインモデルをもとにコミュニケーションを取りながら、適切なコードを書くわけです。

ドメイン駆動設計は、業務仕様やナレッジとコードを一体化させる手法です。業務の実現や顧客の課題解決が第一であり、最新の技術や開発手法の活用は必須とされません。

ドメインとは「アプリケーションが対象とする業務領域」を指す

ところで「ドメイン」とは、何を指すのでしょうか。ドメインとは、アプリケーションが対象とする業務領域を指します。例えば物流システムならば物流業務、会計システムなら経理業務となるわけです。

システムにより解決すべき課題の多くは、ビジネスルールをどう実現するかということが出発点です。このため開発にあたる技術者には、顧客の業務と真摯に向き合うことが要求されます。

ドメイン駆動設計の原則

ドメイン駆動設計には、4つの原則があります。わかりやすく示した文章を、以下に示しました。

・業務仕様やビジネスルールの複雑さを紐解き、顧客の課題を正しく理解する

・業務の専門家とソフトウェアの専門家が協力し、ドメインモデルを作る

・ドメインモデルを明示的に表現するコードを書き、ソフトウェアを作る

・エンジニアである方もそうでない方（業務担当者など）も理解できる共通言語を使って会話する

どの項目も、業務ファーストの姿勢を示していることが特徴に挙げられます。

ドメイン駆動設計を活用する3つのメリット

クリックして拡大

ドメイン駆動設計が注目された理由には、さまざまなメリットを得られることが挙げられます。ここからはおもな3つのメリットを取り上げ、解説します。「ドメイン駆動設計の理解は仕事に役立つ」ことを実感してください。

業務要件を第一にしたシステムを設計・構築できる

ドメイン駆動設計は、業務で実現すべき要件の実現を第一とする開発手法です。以下の制約を理由として業務ロジックや仕様を変えることは望ましくありませんが、実務ではよくありがちです。

・開発言語やプラットフォーム

・使用するソフトウェアやアプリケーション

・サーバーやクラウドの性能

・通信速度

・ユーザーインターフェース（UI）

ドメイン駆動設計では「業務仕様が主体。コードは業務仕様を反映するもの」という姿勢をはっきりさせています。「コードに落としにくい機能を削って欲しい」という要望は、起こり得ません。

複雑な機能要件も正しく理解し、コーディングできる

業務のなかには、要件や処理が複雑なものがよくあります。ドメイン駆動設計ならば複雑な機能要件も整理でき、漏れなく正しく理解することが可能です。業務の流れを正確に把握でき、実務に即した設計を実現できます。

またドメイン駆動設計の概念では、オブジェクトが活用されています。数値や文字列、画像など、どのような種類のデータが入るか事前に把握することが可能。正確なコーディングをあと押しします。

リファクタリングも行ないやすく、保守性が向上する

ドメイン駆動設計におけるオブジェクトの活用は、コードの改善やより良いシステムづくりにも役立ちます。変更した際の影響範囲がどこまでおよぶか、データ型の参照関係をもとにチェックできるためです。修正すべき箇所も正確に把握できるでしょう。

このためリファクタリングを行なっても、デグレードが起こりにくくなります。保守性も向上することでしょう。修正のリスクが減るためスピーディーな対応を実施でき、顧客にも喜ばれます。

ドメイン駆動設計で使われる代表的な用語

ドメイン駆動設計では、独特の用語が多く用いられています。代表的な用語と意味を解説しますので、理解に役立ててください。

ドメインモデル

ドメインモデルは、業務仕様やビジネスルールを図や文章で表現したものです。しばしば開発者と顧客との共通言語として使われます。

ユビキタス言語

ユビキタス言語は、ステークホルダーすべてが理解できる言語です。ドメイン駆動設計では、ドメインモデルが選ばれる場合が多くなっています。

ビジネスルール

ビジネスルールは、業務の遂行にあたり守るべき約束事やルール、決定事項などを指します。組織で行なう業務は、誰が担当しても正しく行なわれなければなりません。このためどの業務でも、ビジネスルールは不可欠です。

パターン

ドメインモデルを実装し表現する手法を指します。パターンに含まれる項目は多種多様です。以下に代表的なものを挙げました。

・値オブジェクト（ルールを書くことが可能な構造体）

・エンティティ（値オブジェクトに代入できるもの）

・リポジトリ（データベースにアクセスするためのオブジェクト）

ドメイン駆動設計を用いた開発の流れ

クリックして拡大

ドメイン駆動設計を活用した場合、システム開発の流れは通常の場合と異なる点があります。この記事では、5つのステップに分けて紹介します。開発の流れを確認していきましょう。

システム化の対象となる業務内容を調査する

ドメイン駆動設計の出発点は、業務内容と課題の把握です。以下の取り組みを行ない、顧客の業務内容や課題、あるべき姿などを認識しましょう。

・業務分析を行なう

・ドメインエキスパート（業務担当者や、業務に関する豊富な知識を持つ方）との対話

特にドメインエキスパートとの対話をおろそかにしてはいけません。なぜならドメイン駆動設計は、今ある仕組みをシステム化するとは限らないためです。課題を把握しあるべきシステムを組むには、第一線で業務に携わる方との対話が欠かせません。

業務の仕様をモデル化する

業務の仕様を把握したら、ドメインモデルとして「見える化」しましょう。図はもちろん、文章などでも表現できます。見やすく、かつわかりやすく示す方法がベストです。

この段階では、まだ技術的な話題は登場していません。モデルは業務内容を反映していますから、ITに詳しくない顧客とのコミュニケーションも取りやすいでしょう。

両者の認識に相違があると、手戻りが大きくなります。納得いくまで議論を重ね、良いドメインモデルを作り上げましょう。

業務のロジックを抽出する

ドメインモデルが確定したら、業務のロジックを抽出しましょう。適切なコーディングには、適切なロジックの把握が欠かせません。ドメインモデルに含まれるビジネスルールを洗い出し、ロジックに落とし込みましょう。可能であればコードで示すことも、良い方法の一つに挙げられます。

コードに落とし込む

業務のロジックが抽出されたら、示されたロジックに対して忠実にコーディングし、ドメインモデルを表現します。「コーディングしにくい」などの理由で、勝手にロジックを変えてはいけません。

ドメイン駆動設計では、オブジェクトが用いられています。このため開発言語は、オブジェクト指向に対応した言語が選ばれることでしょう。

継続的に見直し、ブラッシュアップする

ドメイン駆動設計による開発は他の手法と同様に、一度の開発で完璧にはできない場合が多いです。課題を解決するフェーズを繰り返し、品質を上げることになるでしょう。完成後も事業を取り巻く情勢の変化に合わせて、ドメインモデルの見直しを要します。

このためドメインモデルは継続的に見直し、ブラッシュアップする取り組みが必要です。またドメイン駆動設計は、アジャイル開発を選ぶケースが多くなるでしょう。

ドメイン駆動設計を成功させる4つのポイント

ドメイン駆動開発を成功させ顧客にフィットしたシステムを納品するためには、4つのポイントを押さえることが重要です。各ポイントで行なうべき項目を理解し、プロジェクトの成功に役立てましょう。

オブジェクト指向の理解

すでに解説したとおり、ドメイン駆動設計ではオブジェクトを使って業務やデータの流れを整理します。オブジェクトがわからなければ仕様も理解しにくく、適切なコーディングも行ないにくくなります。

このためドメイン駆動開発に携わる方は、オブジェクト指向の理解が必須です。JavaやC#など、オブジェクト指向に対応した言語を学ぶことは良い方法の一つです。

ドメインモデルはエンジニアでない方でもわかるように表現する

ドメインモデルは、エンジニアでない方でもわかるように表現しましょう。なぜならドメインモデルはこれから作るシステムの業務仕様であり、顧客とやり取りしながらブラッシュアップするものであるためです。

現場の第一線で働く方がわからないドメインモデルでは、議論ができません。顧客の要望も取り入れにくくなるでしょう。業務に役立たない成果物ができあがったのでは、システムを作る意味がありません。

データベースとのやり取りはリポジトリを使う

開発を行なう際には、データベースとやり取りする手法にも工夫が必要です。データベースアクセスのプロセスはリポジトリを活用し、ドメインオブジェクトと分離することをおすすめします。

これにより業務プロセスに手を加えることなく、データベースの切り替えが可能です。稼動中のデータベースに影響をおよぼすことなく新しいコードをテストでき、迅速かつ適切なメンテナンスを実現できます。

関連するドメインとの連携や共有も考慮する

ドメイン駆動設計にあたっては、関連する他の業務との連携やデータの共有も考慮しましょう。例えば、業務間で整合性を取るべき処理やデータが挙げられます。共通化により、効率アップにつながります。

状況によっては、別々に行なうべきケースもあることに注意が必要です。「同じ処理、同じデータなのでひとまとめにする」と短絡的に考えず、別々に持つべきか共有すべきか熟慮して決めましょう。

ドメイン駆動設計を理解し、開発業務に活かそう

ドメイン駆動設計は難しいといわれますが、顧客に役立つシステムの提供には有効です。技術にこだわりのあるエンジニアにとって、ドメイン駆動設計が目指す「業務ファーストの取り組み」は受け入れがたいかもしれません。しかし顧客に納品するシステムは、業務に役立ってこそ対価を得られるものです。業務にこだわる進め方は、理にかなっているといえるでしょう。

ドメイン駆動設計への期待は、ますます高まると予想されます。この機会にしっかり理解し、開発業務へ活かしましょう。

なお、そのほかの開発手法についても気になる方は、こちらの記事をご覧ください。

・スクラム開発を徹底解説！メリット・デメリットも紹介
・今こそ知っておきたい「ウォーターフォールモデル」を徹底解説
・アジャイル開発とはどのような開発手法か徹底解説
・プロトタイプモデルとは？メリットやデメリット、他の開発手法との相違点も解説