はじめに
チームで「この開発は DDD でやろう」と言ったとき、「DDD」は同じ意味で使われているでしょうか ?
人によって「DDD」という言葉の理解は違うと思います。
この記事には、何が DDD で、何が DDD でないか、自分の考えをまとめました。
なお、この記事では
- 『エリック・エヴァンスのドメイン駆動設計』を「DDD 本」
- 『実践ドメイン駆動設計』を「IDDD 本」
と略すことにします。
DDD の全体像
まずはじめに、DDD の世界に登場する概念を分類してみました。
図の通りですが、DDD に登場する概念は大きく「戦略的設計」と「戦術的設計」に分かれます。
さらに、戦略的設計は「思想」と「システムの分割・結合」の話、戦術的設計は「レイヤー構成」と「ビジネスロジックの実装方法」の話に分かれます。
これらの概要を順に説明していきます。
戦略的設計
戦略的設計は、具体的な細かいテクニックである戦術的設計よりも大局的な話です。
※ 図にも書いていますが、システムの分割・結合についての話を「戦略的設計」と呼ぶ場合もあるようです。
思想
DDD の思想についてこの記事では詳細に立ち入りませんが、めちゃくちゃざっくり言うと、「みんなでユビキタス言語を使ってドメインエキスパートと話して、ドメイン知識をそのままソフトウェアで表現しろ」みたいな話です。
私の理解では、この思想が DDD のコアであり、これが抜けている場合は DDD とは呼べないと思います。
戦術的設計だけを使うことを「軽量 DDD」と呼ぶことが多いですが、思想が抜けている場合も「軽量 DDD」と言ってしまっていいかもしれません。
システムの分割・結合
大きなシステムをどこでサブシステム (今風に言うとマイクロサービス) に分割し、どのように結合するかという話です。
システムをどこで分割するかはとても難しい話だと思いますが、IDDD 本には、「ユビキタス言語に注目して、言葉の意味が変わったらそこが境界だ」といったヒントが書かれていたりします。
また、腐敗防止層や共有カーネルといった、システムの結合方法についての論点もあります。
戦術的設計
戦術的設計は、1 つのアプリケーションを具体的にどう実装するかというテクニックの話です。
DDD の話になったときにまず最初に出てくるのが戦術的設計ですが、戦術的設計だけを使うのは「軽量 DDD」というアンチパターンとされることが多いです。
レイヤー構成
コアなロジックを持つドメイン層をいかに隔離するかという話です。
DDD 本では「レイヤードアーキテクチャ」が、IDDD 本では「ヘキサゴナルアーキテクチャ」が紹介されていますが、「オニオンアーキテクチャ」や「クリーンアーキテクチャ 」を採用しても構いません。
要するに、ドメイン層をどうやって分離するかというパターンがいくつかあって、どれを採用するかという話です。
ビジネスロジックの実装方法
Entity、Value Object、Aggregate などを使って、ビジネスロジックをどう実装するかという話です。
これは、いつでも必ずこう実装しろという話ではありません。
ビジネスロジックの実装には
- ドメインモデルパターン
- トランザクションスクリプトパターン
の大きく 2 つがあります。
DDD の文脈で説明されるのはドメインモデルパターンで具体的にどう実装するかという話ですが、どちらのパターンを採用すべきかは状況次第です。
DDD であっても、コアドメイン以外はトランザクションスクリプトで構わないということもよく言われます。
おわりに
DDD のコアは「みんなでユビキタス言語を使ってドメインエキスパートと話して、ドメイン知識をそのままソフトウェアで表現しろ」みたいな思想にあると思います。
とはいえ、戦術的設計が身に付かないまま思想の話をされても具体的に実装するか想像できないと思いますし、まずは戦術的設計から挑戦するのも悪くないと思います。
私は戦術的設計を使ってみただけでも様々な悩みに遭遇し、その悩みを解決するために Aggregate や CQRS といった要素が必要だということに気付いたとき、自分が一歩スキルアップした気持ちになりました。
私は DDD でやれと主張するつもりは全然ないのですが、思想として面白いですし、設計力を高める上で参考になる要素が非常にたくさんあるので、勉強する価値は非常に高いと思います。
参考
書籍
- エリック・エヴァンスのドメイン駆動設計
- 実践ドメイン駆動設計
- ．ＮＥＴのエンタープライズアプリケーションアーキテクチャ 第２版
- 「実践ドメイン駆動設計」から学ぶDDDの実装入門
- Clean Architecture
Web
