「軽量DDD」とは

「軽量DDD」という言葉は『実践ドメイン駆動設計』の中で以下のように表現されています。

軽量DDDとは、DDDの戦術的パターンの一部だけをつまみ食いする方法で、ユビキタス言語を見つけ出して育てていこうなどという気は毛頭ない。おまけにこの手法は、境界づけられたコンテキストやコンテキストマッピングも使わずに済ませることが多い。技術面だけに注目して、技術的な問題だけを解決したがっているのだ。この方法にはメリットもあるが、戦略的モデリングを併用したときのような大きな見返りは得られない。

―――Vaughn Vernon (2013)、高木正弘訳 (2015)『実践ドメイン駆動設計』

DDDの戦術的パターンというのは、エンティティや値オブジェクト、リポジトリ等を指します。
「メリットもある」のですが、一方でこれらの実践がDDDに繋がるわけではないのです。

DDDとは

そもそもDDDとは一体どのような手法なのでしょうか？

今現在の自分の認識では、DDDとは解決領域のモデルを洗練させる過程で、モデルをそのままの形でソフトウェアにも反映させることで、副次的にソフトウェアの品質を上げる手法だと考えています。
つまり、まずはモデルであり、次にソフトウェアです。

では、どのようにモデルを洗練させるのでしょうか？
モデルを洗練させるためには、モデルをより深く洞察することが必要になります。
DDDにおいては、実際に動くモデルを構築することを通じて、モデルを更に深く洞察します。
この動くモデルこそがソフトウェアです。

つまり、DDDでは、

モデルを作る
モデルを基にソフトウェアを構築する
ソフトウェアの構築によるフィードバックからモデルを洗練する
洗練されたモデルからソフトウェアを改善する
ソフトウェアの改善によるフィードバックからモデルを更に洗練する
更に洗練されたモデルからソフトウェアを更に改善する
…

というループでモデルの洗練を通じて、副次的にソフトウェアの品質を上げるのです。

「軽量DDD」は軽量のDDDではない

「軽量DDD」が主軸に置くDDDの戦術的パターン、つまりエンティティや値オブジェクトなどは、DDDにおいてどのような役割を果たしているのでしょうか？

まず、これらの位置づけをEvansの言葉を借りて表現します。

「第2部：モデル駆動設計の構成要素」では、オブジェクト指向ドメインモデリングにおけるベストプラクティスのコアを要約して、基本的な構成要素の集まりを作り上げる。ここでは、モデルと動作する実用的なソフトウェアとの間にある溝を埋めることに重点を置く。ここで述べる標準的なパターンを共有することによって、設計に秩序がもたらされる。また、チームメンバーは互いの仕事をより容易に理解するようになる。標準的なパターンを使用することで、共通の言語に用語法が提供され、この共通の言語を使って、チームメンバ全員が、モデルと設計上の意思決定について議論できる。
しかし、第2部でいちばん重要なのは、モデルと実装を互いに整合させ、片方がもう一方の有効性を補強する状態を維持するような意思決定に集中することである。こうした整合性を維持するためには、個々の要素の詳細に注意する必要がある。こうした小規模の要素をていねいに作り上げれば、第3部と第4部で示すモデリングアプローチを適用するにあたって、開発者は、その基となる安定した土台を与えられるのだ。

―――Eric Evans (2003)、今関剛他訳 (2011)『エリック・エヴァンスのドメイン駆動設計』（強調は筆者）

Evansは、エンティティや値オブジェクトといった実際のソフトウェアにおける構成要素に関して、その存在目的を「モデルと（中略）ソフトウェアとの間にある溝を埋めること」、「モデルと実装を互いに整合させ」ることとしています。

エンティティや値オブジェクトは、モデルをそのままの形でソフトウェアとして表現する際の、オブジェクト指向における「パターン」でしかありません。
つまり、DDDという思想の、さらに一部を補助する詳細です。

これらを用いるだけの「軽量DDD」は、やはりDDDではありません。

「軽量DDD」はDDDではないが、悪でもない

「軽量DDD」は軽量のDDDではありませんが、だからといって悪であるわけではありません。
何かしらのモデルをそのままの形でソフトウェアとして表現するという部分で、「軽量DDD」で挙げられるノウハウの部分は間違いなく利用できます。

ただし、この何かしらのモデルの質が低ければ、同じ構造のソフトウェアの質も低くなります。
そして、これこそがドメインモデル貧血症の正体です。

まとめ

DDDとは、前述の通り、解決領域のモデルを洗練させる過程で、モデルをそのままの形でソフトウェアにも反映させることで、副次的にソフトウェアの品質を上げる手法です。
モデルの洗練なくして、DDDは成り立ちません。
ゆえに、「軽量DDD」はDDDではない、ということを個人的には強く主張したいと思います。

「軽量DDD」と呼ばれているこれに、よりよい名付けが為されることを願います。

最後に

普段はTwitterでDDDについて考えていたりします。
もしよろしければフォローしていただけると嬉しいです。

記事への感想・指摘等もいただけるととてもありがたいです。

@hidollara