DDDとは
DDDは、Domain-Driven Designの略で、ドメイン駆動設計と訳されます。エリック・エヴァンス氏が、著書『Domain-Driven Design』(以降DDD本)で提唱している開発方法論です。同書のサブタイトルには「Tackling Complexity in the Heart of Software」(ソフトウェアの核心にある複雑さに立ち向かう)とあります。複雑化するシステムにおいて、いかにユーザのニーズを把握、実現し、保守・拡張していけば良いかの戦略を示したものです。
同書は、一部のエンジニアには、マーチン・ファウラー氏の『エンタープライズアプリケーションアーキテクチャパターン』(以降PofEAA)と並び、システム設計におけるバイブルとされ、熱狂的に支持されています。残念ながら同書の邦訳は出版されていません。酷い訳ながら邦訳本が手に入るPofEAAに比べて、敷居は高いですが、学ぶだけの「ご利益」はあります。
DDDでは、ソフトウェアが複雑になるのは、対象とするドメイン(問題領域)が複雑だからであると仮定しています。複雑なドメインを解きほぐして理解可能なものとし、的確に把握すれば、複雑さは軽減されるということが前提になっています。
DDDを知るべき人
日頃、以下のようなことを問題として認識している方は、DDDがその解を提供してくれる可能性があります。
- 要件・仕様の決定において、顧客と話が噛み合わない
- 詳細設計まで内製し、実装を外注しているが、成果物に不満足
- ソフトウェアの仕様書と実装が乖離していて、ソースコードしか信用できるものがない
DDDを知る価値が薄い人
DDDの前提、
「ドメインが複雑だからシステムが複雑になるんだ」
ということに共感を得ることができない方は、DDDを知る意味があまりないでしょう。
システムが複雑になり、開発や保守が困難になるのは、ソフトウェアそのものが複雑だからという認識の方、例えば、あなたが日々頭を悩ましているのが、
- Hibernateでパフォーマンスが出なくて困っている
- Ajaxのフレームワーク、どれが良いのか分からない
- 異なるベンダーのSOAツールが、相互接続性が低くてつながらない
といったことであれば、その解をDDDを求める努力は徒労に終わるでしょう。実装レベルでのフレームワークの選定や、パフォーマンスチューニング、開発ツールの使い方といった実装よりのところに興味の関心があるのであれば、個別の技術要素についての解説ドキュメントを当たるべきです。
確かに、あなたにとって、Hibernateが余計なUPDATE文を発行して、更新しなくていい(してほしくない)データまで更新してしまうのは、重大な問題でしょう。しかし、それは、あなた(のチーム)がHibernateのダーティチェックを理解していないだけであり、システムの複雑さに起因するものではありません。多機能で重量級のフレームワークや開発ツールは、それだけ習得に時間がかかります。ただそれは時間が解決してくれる種類の問題です。複雑なのではなく、知るべきことが多いのです。
DDD本の構成
書籍『Domain-Driven Design』は、いわゆるパターン本であり、37のパターンが収録されています。ただ、GoFの『デザインパターン』のように、フォーマットが統一されたパターンカタログの形式ではありません。読み物的普通の文章の中でパターンが解説されています。
DDD本は、4部構成になっています。
【第1部 ドメインモデルを働かせる】
DDDでは、開発者とユーザやドメイン専門家が、ドメインモデルを介して会話するための方法が説明されています。ドメインモデルは、通常イメージされるUMLのクラス図に限ったものではありません。ドメインを記述するモデル、図表や自然言語による記述全てがドメインモデルです。
開発者がドメインを理解した証として、ドメインモデルを作成します。ドメイン専門家(その道のプロ、通常はシステムのユーザ)は、自分の言ったことが開発者にちゃんと伝わっているのかを、ドメインモデルを見て判断します。このように、ドメインモデルは、意思疎通のための「言語」であり、開発者のみならず、ソフトウェアエンジニアではないユーザにも理解可能なものでなければなりません。
第1部では、以下の3つのパターンが紹介され、開発者がユーザやドメイン専門家と会話する「手段」が示されます。
- ユビキタス言語
- モデル駆動設計
- 実践的モデラー
【第2部 ドメイン駆動設計の構成要素】
第1部がDDDの原理原則を述べているのに対して、第2部ではDDDを実践するための、アプリケーションアーキテクチャが示されます。
- レイヤアーキテクチャ
- エンティティ
- 値オブジェクト
- サービス
など、ソフトウェアエンジニアならば、他のパターン本で目にしたことのあるようなものが並んでいます。これらの部品(Building Blocks)を用いて、ドメインモデルをどのようにソフトウェアへと落とし込んでいけば良いのかが示されます。
【第3部 より深い見識へ向けてのリファクタリング】
第3部では、ドメインをより深く理解し、モデルを洗練させていくための手法が述べられます。一回目で完璧なモデルは作れません。タイトルにあるように、第2部の「部品」を使ってモデリングされたドメインモデルを「リファクタリング」することに深化させていく訳です。 リファクタリングの手法として、
- 副作用のない関数
- 表明(Assertion)
といったパターンが挙げられています。
【第4部 戦略的設計】
第3部までは、単一のシステムをどうモデリングし、設計するかが述べられます。これに対して第4部では、複数のシステムを連携させたり、企業としての標準アーキテクチャを制定したりするための手法が述べられます。
本連載は、「実践」を常に意識し、パターンを現場で活用するための方法を実例を挙げて説明していきたいと考えています。しかし、残念ながら、第4部は本連載で扱うにはスコープが大きすぎて、リアリティのある実例を挙げるのも難しいので、範囲外とする予定です。
まとめ
今回は、DDDが何であるか、そしてDDD本の内容はどんなものなのか、概要を説明しました。次回は、最初のパターン「ユビキタス言語」を現場で実際に使うにはどうすれば良いのかをテーマとします。
