DDDってなんでオニオンとかといっしょに出てくるの？を社内で聞いてみた

この記事は夏のリレー連載2024初日の記事です。

夏のリレー連載の企画ということで今回はいつもとは趣を変え、筆者が社内Slackに「DDDってなんでオニオンとかといっしょに出てくるの？」と聞いたときのやり取りを紹介したいと思います。記事化の目的には筆者自身が技術的に「へぇー」と思ったことのアプトプットもありますが、それ以上に豆蔵の雰囲気を少しでも知ってもらえればいいなという思いもあります。読んでもらい豆蔵の社風的なものを少しでも感じ取っていただければ幸いです。

やり取りはいいから結局なんでなの？を取り急ぎ知りたい人向けに聞いた結果の結論を筆者なりの見解としてまとめると次のようになります。

• DDDに特定のアーキテクチャは必要ない
• 必要なのは技術的な関心事とビジネス上の関心事を分離することができるアーキテクチャだけ
• 技術とビジネスの関心事の分離を直接的に実現するには依存関係逆転の法則(DIP)が必要
• これにはDIPを基盤としたオニオンやヘキサゴナル、クリーンアーキテクチャといったアーキテクチャスタイルがフィットする
• なのでDDDとDIPを基盤としたアーキテクチャが一緒に語られるものと思われる

また、レイヤードアーキテクチャは、DDDにフィットしないということではなく、more betterな選択肢としオニオンやヘキサゴナル、クリーンアーキテクチャがあるだけで、レイヤードアーキテクチャなDDDが否定されるものではないとも理解しました。

それはあるクラウドアプリケーションのソフトウェアアーキテクチャをお客様と一緒に検討していたときのこと、お客様からおもむろに

「DDD(ドメイン駆動設計)は設計手法なので、厳密にはDDDで規定されたアーキテクチャというのはないと思っているけど、DDDでオニオンアーキテクチャやクリーンアーキテクチャがよくセットで語れますよね。やっぱり今時はオニオンとかなんですかね？」

と聞かれたことでした。これには私もまったく同じようなことを思っていたりしましたが、コレだ！という答えを持ち合わせてなったので、「原書ともいえるエバンスのドメイン駆動設計ではレイヤードアーキテクチャが紹介されているのになんでですかね」とその場はお茶を濁して終わりにしました。

その場はお茶を濁して終わりにはしましたが、個人的にはお客様に聞かれたのに答えられなかったという以上に、「言われてみればそうだよなぁ～なんでなのかなぁ～」とモヤモヤと気になっていました。

そんなときに頭に浮かんだのが「そうだ！社内で聞いてみよう！」でした。社内にはDDDやアーキテクチャに詳しい人や好きな人が沢山いるんですよね。

豆蔵では希望者にはSlackのアカウントが与えられ、ほぼ全員がSlackのアカウントを持っています。今ではすっかりコミュニケーションツールとして社内に浸透し、プロジェクト内の連絡・報告だけにとどまらず、プロジェクトや事業部といった組織を超え、技術的なことから趣味的なことに至るまで、いろいろな議論や会話が行われています。

そんな社内Slackで筆者が先ほどの疑問を聞いてみた実際の内容を一部デフォルメして、紹介したいと思います。

筆者：【緩募】知っている方がいましたら教えてください
DDDでオニオンアーキテクチャやClean Architectureがセットで語れらる由縁をご存じの方いますか？

最近といいますか、よくネットの情報ではDDDとセットでオニオンやヘキサゴナル、Clean Architectureなど依存性逆転の法則を使ったアーキテクチャパターン（アーキテクチャスタイル）がセットで語られています。一方でDDDそのものは設計や実装のパターンやノウハウにフォーカスしたもので、ソフトウェア全体のアーキテクチャをどうこうすべきということは言及してないと理解しています。むしろ原典のEric EvansのDDD本ではDDDを実現するアーキテクチャとしてレイヤードアーキテクチャが紹介されています。

なんでそんなことを知りたいかというとあるお客様から今どきレイヤードアーキテクチャってどうなのよ？的なことを聞かれたことです。

レイヤードアーキテクチャだろうがClean Architectureだろうが、目的とそれぞれのメリデメに合わせて決めればいいだけで、それ自体はどうでもいいのですが、コメントする上でDDDとそれらの出典を理解したうえでコメントしたいと思っているのですが、「実践ドメイン駆動設計」でレイヤードアーキテクチャよりもベターな例としてヘキサゴナルアーキテクチャが紹介されているのは確認できたのですが、オニオンとClean ArchitectureについてはDDDとセットで語られている出典を見つけられず、、、

どなたかご存じではないでしょうか？（オニオンもClean Architectureもヘキサゴナルも似たようなものだからひとまとめにして的な流れで語られているのかなぁとは思っていたりしますが）

IMさん：これどうでしょう。クリーンアーキテクチャ完全に理解した

(ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャが本質的に同じであることの解説はドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か(DDD) - little hands' labが分かりやすかったです。)

ですって。

筆者：情報ありがとうございます！いただいたリンクの情報は以前より知っていて、そうですよね！とは思うのですが、それぞれのアーキテクチャとそれがなぜDDDとセットでうれしいのか？が理解できず・・あくまでも俺の考えたアーキテクチャ論の域をでないんだよなぁということで、説明の引き合いに出すのは弱くな感じです。

IMさん：

• ビジネスルール を ドメイン知識 とかにマッピングしてて、
• DDDの実装例でレイヤーでやるといいよって説明してて、
• レイヤーを丸くしたいろいろなアーキテクチャーが発展したから
• 全部大体同じってわかるよね

ということでは。
とはいえ出典は見つけられず。

SZさん：Learning Domain-Driven Designはどうですか？

筆者：この本いいですね。オライリーのe-leaning^[1]でさっそく斜め読みしてきました。
挙げられているのはヘキサゴナルでしたが、それがどれだけうれしいかは別としてDDDではレイヤードアーキテクチャよりなぜいいかは理解できました。

要はDDDは読んで字のごとくドメインにフォーカスしているので、ドメインをクリーンにすることが重要。なので、その意味では依存性逆転を使ったヘキサゴナルはレイヤードアーキテクチャよりベターってことですね。

出典は不明ですが、そのドメインをクリーンに保つというコンテキストでオニオンもClean Architectureも一緒に語られるのだろうということですごく腹落ちしました。

INさん：オライリー内をさっと検索しただけですが、Patterns, Principles, and Practices of Domain-Driven Designとかどうですか。
"Patterns, Principles, and Practices of Domain-Driven Design"の"8 Application Architecture"の最後で、
"DDD does not require a specific architecture—only one that can separate the technical concerns from the business concerns."といってますね。

筆者：この本もいいですね。それぞれのレイヤーの責務やなぜ必要なのかが明確にハッキリ書かれていますね。今までの理解の再確認やそういうことかと思うことがパパっと読んだだけでも結構ありました。

DDDとついている本の中では一番実践的な気がしました。その中でもINさんも挙げているように、

DDD does not require a specific architecture—only one that can separate the technical concerns from the business concerns.

DDDがレイヤードアーキテクチャでなくなぜオニオンやヘキサゴナルなのかはこれに尽きるんですね。ここまでバツっと言ってくれると気持ちいいです。
情報ありがとうございましたｍｍ

KDさん：DDD との直接的な関連はないと思うんですが、マイクロサービスの文脈ではビジネスロジックと外部との通信に使用するアダプタを分離するヘキサゴナルアーキテクチャがよく登場する気がします。

リチャードソンのマイクロサービスパターンなんかは全面的にヘキサゴナルで語られていますし、マイクロサービスを切り出す際に DDD のアグリゲート(集約) を利用したりしています。

レイヤードは、アプリの内部的な構造にフォーカスしているのに対し、ヘキサゴナル的なアーキテクチャは集約単位に分離されたマイクロサービスの連携を可視化しやすいのではないかと思いました。

なのでマイクロサービスな文脈で DDD と ヘキサゴナルがセットで語られていたりするのかもと思ったり。
(オニオンとヘキサゴンとクリーンの違いもわかってなくてすごく適当なこと言っているかも。あくまで私個人の感想です。)

筆者：ちなみにお客様から聞かれているもう一つのお題があるのですが、それは「マイクロサービスとクリーンアーキテクチャもセットで語られることが多いけどそれはなぜなーぜ？」でまさにKDさんがいわれていることでした。

ただ、私は、マイクロサービスはサービスをどう分割するかが肝で、それに対してDDDの境界づけられたコンテキストやコンテキストマップとかの相性がいいので、その繋がりで

• マイクロサービスといえばDDDの境界づけられたコンテキスト
• DDDといえば依存関係逆転の法則を使うのが吉
• 依存関係逆転の法則といえばオニオン、ヘキサゴン、クリーンの3兄弟

という三段論法でマイクロサービスとクリーンアーキテクチャが飛躍してでてきているだけと考えていましたが、ヘキサゴナルはアーキテクチャ的にもフィットするというのはありますね。

レイヤードアーキテクチャはRESTが出てくる前の画面＋BL＋DBで完結するアプリにはジャストフィットしましたが、REST全盛の昨今ではRestClientの処理をどこに置くかなど、ムズムズするんだよなぁというのは正直ありました。

なので、そう考えるとヘキサゴナルはあっている気はしますし、集約の単位でマイクロサービスを切り出すのもわかりやすいですね。と、リチャードソンのチョコ本は以前読んだのですが、そんなことはすっかり抜け落ちていたので、もう一回勉強してきますｍｍ

KDさん：「境界付けられたコンテキスト」も出てましたね。
分散システムにフィットする表現方法な気がしますね。ヘキサゴナルとかは。
既出かもですが、何年か前に「クリーンアーキテクチャなんてないんだよ」っていう記事が出てましたね。

Slackのやり取りをある意味なまなましく紹介させていただきましたが、どうでしたでしょうか？豆蔵には技術が好きで、そして大事にしているエンジニアが大勢います。こんなところで働いてみたいなと思っていただいた方は是非、ページの一番下にある中途採用サイトのバナーをポチっとしていただければと思います（最後はそこかよ！的な感じで）