注目イベント!
アドベントカレンダー2024開催中!
一年を締めくくる特別なイベント、アドベントカレンダーを今年も開催しています!
初心者からベテランまで楽しめる内容で、毎日新しい技術トピックをお届けします。
詳細はこちらから!
event banner

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

| 6 min read
Author: toshio-ogiwara toshio-ogiwaraの画像

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

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

TL;DR

#

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

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

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

きっかけはお客様からの質問から

#

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

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

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

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

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

Information

記事ではアーキテクチャスタイルとして、レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャの4つを引き合いに出していますが、それぞれの詳細は説明していません。それらが何かを知りたい場合は 旬なアーキテクチャって何だろう?|SOMPOシステムズ(株)【公式note】 を参考にされるのがよいと思います。それぞれの概観が平易に分かりやすく説明されています。

さっそくSlackで聞いてみた

#

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

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

登場人物の紹介

筆者:エンタープライズなJavaアプリを作りつづけて25年のアラフィフエンジニア。ここ数年は大規模基幹システムを支えるJakartaEEフルスタックなフレームワークの開発に加えSpring Bootに注力した開発をしている
IMさん:とある金融系基幹システムのプロジェクトリーダー。要件定義からモデリング、実装まで何でもこなすアラフィフのナイスガイ
SZさん:アジャイルやクラウドアーキテクチャの技術コンサルとして様々なお客さまの課題を解決するスーパーエンジニア。たぶんアラフォーとアラフィフの間
INさん:社内外を問わず活躍されているオブジェクト指向界のまさに重鎮。自社の人間を重鎮というのは少しイタい気がするが、名前を聞いて重鎮ということに異を唱える人は恐らくいないでしょう
KDさん:業務では管理職っぽいこともやっているがそれは仮の姿で、とあるフリーソフトの作者だったりもするプログラミングをこよなく愛する言語厨のアラカンも見えてきたスーパープログラマー

筆者:【緩募】知っている方がいましたら教えてください
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も一緒に語られるのだろうということですごく腹落ちしました。

Learning Domain-Driven Designの翻訳本が出版されました

記事を書いている時点では未発売でしたが、Learning Domain-Driven Designの翻訳本が ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 として出版され、日本語で読めるようになりました!興味がある方は 「ドメイン駆動設計をはじめよう」を読んだので紹介します の書評をどうぞ

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

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

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

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

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

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

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

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

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

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

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

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


~ ここら辺から徐々に別の話題に移り、楽しい議論はこの後も続きましたが、キリがないのでSlackのやり取りの紹介はここで終了とさせていただきます ~

最後に

#

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


  1. 豆蔵では社員教育の一環として、洋書や(一部)和書が読み放題のオライリーのe-leaningのアカウントか、膨大な数の講座を受講可能なudemy bussinessのアカウントのどちらかを希望でもらえます ↩︎

豆蔵では共に高め合う仲間を募集しています!

recruit

具体的な採用情報はこちらからご覧いただけます。