なぜDDD初心者はググり出してすぐに心がくじけてしまうのか

背景

直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。

一番にですね、大体のDDDに興味を持った人がいうのが

「単語が難しいばかりで結局イメージが湧かない」

「ドメイン駆動の本を読もうとして速攻で心が折れた」

ということなんですよね。

DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！

という点について、私なりの解釈を述べたいと思います。

心をくじく要因

Eric Evans本は説明が圧倒的に下手。笑

ドメイン駆動設計といえば原著がこの本(以下、原典)なのですが、

エリック・エヴァンスのドメイン駆動設計

この本は本当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまりがないのです。一通り実装してからも結局この結論になるので、あの本でわからないのは仕方ないです。笑

まず書籍は実践DDD(以下、IDDD)から入るのが良いと思います。

実践ドメイン駆動設計

ここである程度イメージをもたせてから、興味があったら原点に当たるというのが良いでしょう。

DDDは対象領域が広いが、それが理解されずそれぞれ局所的な説明がされていることが多い

DDDの領域は大きく分けて3つに分けられます。

開発思想：
- システムの複雑性に取り組むために、業務の専門家と技術の専門家で言語・モデルの認識を合わせ、継続的に進化させていこう、という考え方
戦略的設計：
- ドメインモデリングの前提を揃えるための、モデリング対象を定義する原則と手法(コアドメイン/サブドメイン、境界付けられたコンテキスト、コンテキストマップ等)
戦術的設計
- モデルを具体的に表現するためのパターン(エンティティ、レポジトリ、レイヤードアーキテクチャ等)

この全体像が整理されないまま、メリットやHowの話になってしまうと、全体像が見えないので何の話をしているのか混乱してしまうのです。

強引に例を挙げるならスクラムの見積もり手法とGoFデザインパターンのいくつかを並べて同時に「開発の効率化とは」と論じるようなものです。それぞれに目的があり、関係性があり、それが繋がって本当にやりたいことができるわけです。

アーキテクチャの話のウェイトが軽い

戦術設計の話で、レイヤー化アーキテクチャについては「ドメイン層を設けてドメインロジックはそこに閉じ込めましょう」ぐらいで終わっていきなりエンティティやレポジトリパターンの話になってしまう。

これも罠だと思っています。なぜなら、

DDD戦術的設計の最大のメリット、同時に一番頭をひねるところはとにかくアーキテクチャにある

と言っても過言ではないと思うからです。

まず、DDDの推奨するアーキテクチャを採用することによっていかにメリットがあるか。ここについてきちんと時間を割き、その後のモチベーションを高めることがまずは重要だと思っています。エンティティ、レポジトリというパターンは、あくまでレイヤーを綺麗に分ける上でのHowでしかないのです。ここのウェイトの認識を間違えないようにすることが重要です。

しかし！ここからはより具体的な問題が出てきます。。

アーキテクチャのお手本が一つに統合されていない

実は、原典でお手本とされているレイヤー化アーキテクチャと、IDDDでお手本とされているアーキテクチャが違うのです。

これは、IDDDでは原典から10年のときを経て洗練されたアーキテクチャになっているということなのですが、これはつまりエンティティなどのデザインパターンは原典でかなり完成されていたのに対して、レイヤー化アーキテクチャに関しては実はある意味未成熟なものであったということ。

そしてそれによりネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。また日本の著名なDDD推進されている方のスライドを見ると、ヘキサゴナルとは思想の異なるアーキテクチャを提案しています。

これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。