ドメイン駆動設計

ドメイン駆動設計（DDD）とは

ドメイン駆動設計（Domain-Driven Design、DDD）は、ソフトウェア開発における主要な設計手法の一つです。この手法は、ドメインエキスパート（業務専門家）の知識を基に、業務プロセスやルールを正確に表現したドメインモデルを構築し、そのモデルに基づいてソフトウェアを開発することに重点を置いています。

DDDの目的

DDDは、以下の3つの主要な目的を達成するために用いられます。

1. 業務領域への集中: プロジェクトの主な焦点を、中核となる業務領域とそのロジックに置くこと。
2. 複雑さのモデル化: 複雑な設計を、ドメインモデルを通じて表現すること。
3. 協調的な関係構築: 技術者とドメインエキスパートの間で創造的な協働関係を築き、ドメイン固有の問題を解決するための概念モデルを継続的に洗練させること。

DDDの構成

DDDは、戦略的設計と戦術的設計という2つの主要な側面に分けられます。

戦略的設計

戦略的設計は、DDDの根幹をなす概念です。ここでは、以下の要素が重要になります。

言葉の意味と文脈: ドメインエキスパートと技術者の間で、共通の言葉（ユビキタス言語）を用いて、業務に対する共通理解を形成します。同じ言葉でも、文脈によって意味が異なる場合があるため、区切られた文脈（境界づけられたコンテキスト）という概念を導入し、言葉の意味を明確化します。
業務領域の分類: 事業活動をその性質によって、中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリックサブドメイン）、補完的な業務領域（サブドメイン）の3つに分類します。これにより、開発リソースを効果的に配分し、戦略的にソフトウェアを構築することが可能になります。

ユビキタス言語

ユビキタス言語とは、ドメインエキスパートと技術者が共通の言葉を使うことで、効率的なコミュニケーションを促進する手法です。この言語は、特定の文脈の中で一貫した意味を持ちます。例えば、金融システムの開発において「口座」という言葉は、技術者と銀行員の間で同じ概念を指す必要があります。技術者はドメインエキスパートと協力しながら、この言語を育て、ドメイン問題を解決するためのモデルを継続的に洗練させます。

区切られた文脈（境界づけられたコンテキスト）

区切られた文脈とは、ユビキタス言語の適用範囲を定めるものです。システム全体を単一のモデルで表現するのではなく、文脈ごとに独立したモデルを構築することで、複雑さを軽減します。例えば、顧客管理と請求管理では、同じ「顧客」という言葉でも異なる意味を持つ場合があります。この区切られた文脈の概念を導入することで、システム全体の一貫性を維持しながら、異なる領域のモデルを効果的に管理できます。

業務領域の分類

DDDでは、ソフトウェア開発を効率化するために、業務領域を以下のように分類します。

中核の業務領域（コアドメイン）: プロジェクトの中核となる、複雑で重要なロジックを含む部分です。競争優位性の源泉となるため、集中的なリソース配分が必要です。頻繁な変更が予想されるため、ドメインモデルなどの高度な設計パターンが適用されます。
一般的な業務領域（ジェネリックサブドメイン）: どのソフトウェアでも共通のアプローチが可能な部分です。外部のソフトウェアやライブラリの利用が推奨されます。例えば、認証処理などが該当します。
補完的な業務領域（サブドメイン）: 事業活動を支えるものの、競争優位性を生み出さない部分です。ロジックが単純で変更が少ないため、トランザクションスクリプトやアクティブレコードのような簡易な実装方法が適しています。

戦術的設計

戦術的設計は、戦略的設計で定義された概念を、具体的なソフトウェアの実装に落とし込む段階です。ここでは、以下の要素が重要になります。

業務ロジックの表現方法: トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式のドメインモデルなど、業務ロジックを表現するための様々なパターンを検討します。
アーキテクチャ方式: 階層化アーキテクチャ、ポートとアダプタ方式など、ソフトウェアの構造を決定するためのアーキテクチャパターンを選択します。

業務ロジックの表現方法

業務ロジックの実装には、以下のパターンがよく用いられます。

トランザクションスクリプト: 手続き的な業務ロジックの実装方法です。プレゼンテーション層からのリクエストを処理する一連の流れの中で、業務ロジックを記述します。
アクティブレコード: ドメインモデルの一種で、モデルがデータベースのテーブルやビューと一対一に対応します。データベース操作が直感的になるというメリットがありますが、モデルの柔軟性に欠けるというデメリットもあります。
ドメインモデル: 業務ロジックとデータを一体化させたオブジェクトモデルです。集約、エンティティ、値オブジェクト、ドメインサービスといった要素で構成されます。複雑な業務ロジックを表現するのに適しており、DDDの中心的な概念です。
イベント履歴式のドメインモデル: 集約の状態変化をドメインイベントで表現するモデルです。過去の状態を再現できるというメリットがありますが、現在の状態を再現するために計算が必要になるというデメリットもあります。

アーキテクチャ方式

DDDにおけるアーキテクチャ設計には、以下の方式が用いられます。

レイヤードアーキテクチャ: アプリケーションをプレゼンテーション層、ドメインロジック層、データアクセス層などの階層に分割するアーキテクチャです。
ポートとアダプタ方式: 依存性の逆転を行うことで、ドメインロジック層がデータアクセス層に依存しないようにするアーキテクチャです。オニオンアーキテクチャ、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどがこの方式に該当します。

その他の概念

DDDには、以下のような関連概念があります。

オブジェクト指向分析設計: DDDはオブジェクト指向の手法と親和性が高く、その強みを活かしてソフトウェアを構築します。
モデル駆動工学（MDE）とモデル駆動型アーキテクチャ（MDA）: DDDとMDAは両立しますが、MDAはドメインモデルの変換に関心があるのに対し、DDDはより良いドメインモデルの定義に関心があります。
POJOとPOCO: これらの概念は、特定のテクノロジに依存せず、ビジネス上の振る舞いを実現するためにドメインオブジェクトを定義するべきである、という考え方を示しています。
Naked Objectsパターン: 良質なドメインモデルがあれば、ユーザーインターフェースはそれを反映したものになるという考え方に基づいています。
ドメイン固有言語（DSL）: DDDはDSLを必要としませんが、DSLの定義を助け、domain-specific multimodelingのような手法の実践をサポートします。
アスペクト指向プログラミング（AOP）: AOPを利用することで、技術的な関心をドメインモデルから分離し、ビジネスロジックに集中した設計を容易にします。

DDDをサポートするツール

DDDの実践は、特定のツールやフレームワークに依存しませんが、以下のツールがDDDをサポートしています。

Castle Windsor/MicroKernel
Cosmos
DataObjects.Net
Domdrides
ECO
Flow
Habanero.NET
ManyDesigns_Portofino
NakedObjectsFramework、Apache Isis
NReco
OpenMDX
OpenXava
Roma Meta Framework
Sculptor
Sculpture
Strandz
TrueView for .NET
* ASP.NET Boilerplate

まとめ

ドメイン駆動設計は、複雑なソフトウェア開発を成功に導くための強力な手法です。ドメインエキスパートと技術者が協力し、ドメインモデルを軸に開発を進めることで、ビジネスニーズに合致した高品質なソフトウェアを効率的に開発できます。DDDの概念を理解し、適切なツールを活用することで、より優れたソフトウェア開発を実現できるでしょう。

もう一度検索