過大評価されるDDD（ドメイン駆動設計）

この記事は、著者の許可を得て配信しています。
Is Domain-driven Design overrated?

ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。

最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはしていません。

ドメイン駆動設計（DDD）は最近、ますます人気を集めています。新しい本や会議での講演、またDDDに関する会議まで行われています。そして数多くのトレーニングなどーーーINNOQの社員直々に実施するものを含みます。何を隠そうそんな私も実はずっと前からDDDの大ファンなのです。しかし、最近数人の人たちのせいで、DDDが少し嫌いになっています。もちろんEric Evans氏のオリジナルの本、Vaughn Vernon氏による執筆や普及活動（例えば、私の同僚Joy Hero氏とのポッドキャストでの素晴らしい内容を本にしたもの）、その他 Mathias Verraes氏, Daniel Terhorst-North氏、同僚のMichael Plöd やEberhard Wolff氏などの多くの人の書いた本や講演などは例外で、すべてこの業界の人たちにいい影響を与えています。いい意味でのパターン言語であるDDDは、多くの開発者やデザイナーがやり方を知っていても、それについて信頼性や互換性のあるコミュニケーションができないものなのです。

しかし、最近、誰かがシステムやサービスの境界をどのように決めるか、あるいは非技術的な設計について言及するたびに、誰もがDDDの専門家を呼び寄せざるを得ないように感じているという事実に、私はイライラしています。まるで彼らだけが何でも設計できるスーパーヒーローであるかのように。これは今流行しているソリューションを盲目的に導入してしまう他の状況と同じです。誰もが話題にしていることだからであり、それが仕事に適したソリューションだからというわけではありません。DDDは素晴らしいものですが、それはあなたが知っておくべき多くのツールやテクニックの一つに過ぎません。

DDDの戦略的次元では、最も頻繁に使用されるツールは、コンテキスト境界(bounded context)という概念です。それぞれが小さいユニットに割り当てられるべきという概念です。これは素晴らしいアイデアです。これも（もちろん）DDDの発明ではありません。単純にモジュール設計であり、文字通り何十年にもわたって大規模なシステムを設計してきた人たちによって適用されてきたものです。それはつまり、コンテキスト境界(bounded context)の概念に何か間違った点があるということでしょうか。いいえ。実際には、しばらくの間存在し、その価値を証明してきたものに名前をつけるのがパターンの目的です。私は、コンテキスト境界というものには欠点があるということを言っているのではありません。私が指摘しているのは、誰かがこの特定のラベルを使わずに、あるいはこの特定のラベルを知らずに、システムのために素晴らしいデザインを作ったかもしれないということです。

戦術的な次元では、みんながもっと重要な側面を見落としていると私は思います。デザイン全般の入門としてDDDを始めたときは特に。DDDはネーミングの重要性を強調しており、デザインの対象となるコンテキストにおいて、共通のユビキタスな言語を目指して努力すべきであることを示唆しています。しかし、DDDは独自の言語も使用しています - コンテキスト境界、アグリゲート、エンティティ、バリューオブジェクトなどの概念です。こういった概念を、私たちのドメインであるシステム設計のドメインのために使用しています。そして、これらはすべてよくできていて良いのですが、考えられる言語の一つに過ぎません。多くの人が理解できる用語であれば、コミュニケーションを容易にするために、バリューオブジェクトをバリューオブジェクトと呼ぶことに価値（バリュー）があります。しかし、既存の一般的なDDDの概念だけが、考慮すべき唯一の概念ではありません。それは、システムを設計・構築する際の一般的な特徴の一例に過ぎません。パターンを考え出して認識し、それに良い名前をつけ、システムの構造と完全性を持たせるためにそれを使用します。もしあなたのアーキテクチャの中で、Filterを使ってリクエストをHandlerにルーティングしたり、 Agentによって処理されるDocument の概念が一般的なパターンであるならば、これらのことはServiceやRepositoriesと同じように何度も何度も発生し、あなたにとってはずっと重要なことになってしまうかもしれません。これでいいのです！

私たちは独自の言語を発明できるし、発明すべきであるというこの概念は、単純な多くのDDD使用者が考えているよりもはるかに重要です。DDDの専門家はこのことをよく知っていて、DDDの資料を最終結果ではなく出発点として見ていると信じたいです。しかし、もしあなたが既存のDDD用語の決まりきった定義を使って、この既存の構造の中に問題を押し込もうとしているだけなら、あなたの設計者としての人生は非常に悲惨なものになるでしょう。

DDDをあなたのツールセットの一部にして、そこで終わりというのはいけません。DDDの先には人生があるのです。すべての優れた設計がドメイン駆動型である必要はありません（必ずしもDDDという意味ではなく、常にドメインによって駆動されるべきであることは認めますが）。DDDの専門家でなくても、良いシステムを設計することはできます。