TRACERYプロダクトマネージャーの haru です。
2024年8月29日(木)に開催された勉強会「BPStudy#204〜ドメイン駆動設計をはじめよう」では、書籍ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法（以降、LDDD*1）の翻訳者とレビュアーをお招きし、パネルディスカッションを実施しました。その時の様子をお伝えします。翻訳者とレビュアーの見解を通じて、書籍をより深く理解し、実践に役立つヒントを得られるでしょう。
シリーズ記事index
- その１: 書籍の魅力と翻訳の舞台裏
- その２: エヴァンス本との相違点 (本記事)
- その３: 「同じ言葉」を日本語で運用するノウハウ
- その４: 重要なツールとして進化した、区切られた文脈
パネルディスカッション参加者
- パネラー：
- 増田 亨(ますだ とおる) 氏(翻訳者：以下、増田)
- 綿引 琢磨(わたびき たくま) 氏(翻訳者：以下、綿引)
- 佐藤 匡剛(さとう ただよし) 氏(レビュアー：以下、匡剛)
- モデレータ：
- haru(本記事の執筆者)
- シリーズ記事index
- パネルディスカッション参加者
- 区切られた文脈への踏み込んだ説明
- 集約、エンティティ、値オブジェクトの扱い
- ドメイン駆動設計に対するありがちな誤解
- 業務を捉えるモデリングの基本技法としてのエンティティと値オブジェクトの重要性
区切られた文脈への踏み込んだ説明
haru：段々とテクニカルな話に入っていきます。「エリック・エヴァンスのドメイン駆動設計」（以降、エヴァンス本*2）。ドメイン駆動設計の原典として広く認知されているエヴァンス本の原書が2003年に出版されて*3から21年経っていることもありまして、エヴァンス本と違いはありましたか、というのを伺いたいです。
匡剛：一番大きいのは構成上の違いです。戦術的設計から入って戦略的設計を説明したのが、エヴァンス本です。LDDDは戦略から入って戦術の説明をしていて順序が逆になっています。そこが一番違う所です。
増田さんと議論していて違いがあったところでいうと、「区切られた文脈の設計」についてエヴァンス本ではモヤっと列挙されていたのですが、LDDDはもっと踏み込んで理路整然と整理し直しています。たとえば、区切られた文脈同士の関係で、モデル変換装置*4と共用サービス*5が対になっているということがエヴァンス本では書かれてなかったんですが、LDDDでは図式化されていて関係を言い切っています。
haru：4章「区切られた文脈どうしの連係」ですね。
集約、エンティティ、値オブジェクトの扱い
匡剛：戦術的設計でいうと、エヴァンス本は集約*6、エンティティ*7、値オブジェクト*8というものがありますよ、という説明でしたが、LDDDは意図的にエンティティの影を薄くしているですね。実質、集約、値オブジェクトの2つに絞られていて、エンティティはほとんど使わないというように格下げされています。このように内容が大胆に組み換えられていて、読者が疑問に思うような内容が省かれています。削ぎ落とされてコアの重要なところだけにされたという感じがします。
haru：まさに蒸留*9されていますね。だからわかりやすいんですね。先日、匡剛さんから頂いた資料*10で、集約の単位についてエヴァンス本はライフサイクルが単位で、LDDDはトランザクションの境界が単位であるという話がありましたが、その点はいかがですか。
匡剛：エヴァンス本では集約はライフサイクルの単位で定義されるという説明しかされていないんですが、LDDDではさらに踏み込んでいて、集約そのものがトランザクションの境界になりますよ、という定義になっています。そこが古典的なエヴァンス本から来た方は、おっと思う箇所ではないかと思います。
haru：ここでいう「トランザクション」はDBのトランザクションのことですかね。
匡剛：そうですね。分散トランザクションもです。
haru：OOA(Object Orirnted Approach)*11の考え方でいうと、DBにあまり踏み込まないイメージだったんですが、トランザクションという言葉が出てくるんだとLDDDを読んでいて思った記憶があります。
増田：集約のところは私は捉え方が少し違っています。LDDDには匡剛さんがおっしゃったとおりに書かれているんですが、エヴァンス本も要点は同じことを言っていると思っています。エヴァンス本もLDDDも集約は「invariant（不変条件）」の単位だと言ってるんですね。業務ルールの一貫した計算ができる単位を集約としましょうということを言ってます。それがオブジェクトのライフサイクルやDBのトランザクションというものに隠れてしまっている。集約は業務ロジックが一貫性を持って判断できる範囲なんです、ということをLDDDではエヴァンス本に比べて強調しています。
あとLDDDで言っているのは集約の範囲は可能な限り小さくすべきだということです。集約というのは、ぎりぎりここまでの範囲ではないと一貫した判断ができない、というところに留めるべきということを何度か強調しています。
私は、ファット*12な集約でうまくいっていないということを現場で何度も見てきてるんで。LDDDに書かれている「業務ルールに対する一貫性は小さくなるし、小さくするべきなんだ」という説明はとても良いなと思いましたね。エヴァンス本にもinvariant（不変条件）とか一応書いてあるんですが、あまり強調してないんですよね。
haru：私も開発でソースコードを読むことがありますが、集約やトランザクションのスコープが大きいなと感じることがあります。
増田：典型的なアンチパターンです。ただ、仕方ない面もあって、今までの参考資料を読んでも、そこまで業務ルールによる一貫性の判断について明確に書いたものはなかったんですよね。
ドメイン駆動設計に対するありがちな誤解
綿引：戦術的な説明が全面に出てないところがLDDDで好きな所です。ドメイン駆動設計でやりたいですという開発案件に入ると、戦術的設計から語られることが多くて、それに違和感を感じることがあります。それがLDDDを読んですっきりした気分になりました。
haru：そもそも論が語られてますよね。LDDDの「訳者まえがき」でも、DDDに関する偏った情報が流れている*13というのが書かれていましたよね（笑）。
LDDDを読むことによって、正しい理解に戻されるというのがあるとおもいますね。業務の3つの分類（中核的業務領域、一般的業務領域、補完的業務領域）など初めて読んだ？とおもったんですよね。実はエヴァンス本にも書かれていたのですが*14。あと、ドメイン、サブドメインなど、実はよく分かっていなかったんだなとLDDDを読んで気づきました。LDDDで「ドメイン」を「事業領域」、「サブドメイン」を「業務領域」と訳してもらったことで私は初めて理解できました。エヴァンス本で、コアサブドメインと書かれていても、コア（中心、メイン）なのかサブなのか、直感的に頭に入ってこない面があったと思います。
業務を捉えるモデリングの基本技法としてのエンティティと値オブジェクトの重要性
増田：実は、今の議論の中で気になることがあって、エンティティをすっ飛ばしてるところとか、値オブジェクトの説明とか、私は相当気に入ってないんですよね。綿引さんのおっしゃるように、実装パターンとして使われてしまっているというところはそのとおりで、戦術的設計のみが独り歩きしないほうが良いと思います。しかし、モデリングという観点でいうと、エンティティと値オブジェクトはビジネスを捉える時に有効なアプローチなんで、そのような切り口で取り上げてほしかったという思いがあります。
業務知識を獲得するために戦術的なモデリングは非常に重要です。関心事をどのような単位で捉えるかということと、お金なのか日付なのか業務なのか、何に関心があるのかということです。そのようにビジネスを捉える時に、エンティティ、値オブジェクトというアプローチはモデリングパターンとして非常に重要だと思ってます。そういう意味でエヴァンス本のアプローチは悪くありません。モデリングパターンではなくて、実装パターンとして理解してしまうと良くないんだと思います。
haru：そもそもの目的は現実の世界をモデリングすることにある、ということが忘れ去られてしまうということに問題がありそうですね。
増田：エンティティと値オブジェクトは、業務を捉えるための基本技法の1つだと思ってます。LDDDの流れの中には含められない内容ではあります。LDDDは書籍としてはよくまとまってると思いますし、設計とかモデリングとか分析設計の考え方からすると思い切ってるなとは思います。
haru：書籍のサブタイトルが「ソフトウェア実装と事業戦略を結びつける」ですが、結びつけるためにエンティティと値オブジェクトは重要なのかなと私も思います。
増田：さきほどの綿引さんの話にあった((イベント第2部の資料：[ドメイン駆動設計を実践するために必要なもの](https://speakerdeck.com/bikisuke/bpstudy-number-204?slide=16)))ように「息を吸うようにコードを書く」と一緒で、息を吸うように値オブジェクトやエンティティを見つけるという感覚が大事だと個人的に思っています。
次回の、「同じ言葉」を日本語で運用するノウハウ〜「ドメイン駆動設計をはじめよう」翻訳者・レビュアー対談その3 - TRACERY Lab.（トレラボ）では、「同じ言葉」の日本での運用についてお伝えします。
*1:原書のタイトルは "Learning Domain-Driven Design"
*2:エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう。ドメイン駆動設計の原典として広く認知されている。
*3:日本語訳は2011年出版。
*4:エヴァンス本では腐敗防止層
*5:エヴァンス本では公開ホストサービス
*6:「集約（Aggregate）」は、ソフトウェア設計においてデータの整合性と一貫性を保つための重要なパターン。集約は、関連するオブジェクトの集合を一つの単位として扱い、外部からのアクセスや操作を制限することで、データの整合性を保証する。集約ルートを通じてデータの操作を行うことで、ソフトウェアの健全性を保ちながら、複雑なビジネスロジックを効率的に実装することが可能になる。
*7:ビジネスドメインの重要な概念やオブジェクトを表現する。エンティティは一意の識別子を持ち、その同一性を基に状態変化を追跡する。適切なエンティティの設計は、ビジネスルールの実装とシステムの一貫性を確保するために不可欠である。エンティティを理解し、正しく設計することで、より堅牢で保守性の高いシステムを構築することが可能になる。例としては顧客(Customer)エンティティ、注文(Order)エンティティなどがあげられる。
*8:ドメイン駆動設計において重要な役割を果たす要素であり、ビジネスロジックの一部をシンプルかつ一貫して表現するための手段。同一性よりも属性の値に焦点を当てることで、値オブジェクトはシステムの予測可能性と保守性を向上させる。適切な値オブジェクトの設計は、ドメインモデル全体の健全性と明確性を確保するために不可欠。例として、住所（Address）、金額（Money）、日付（Date）などがあげられる。
*9:エヴァンス本の15章のタイトル。混ざりあったコンポーネントを分離するプロセスであり、価値があって役立つ形式で本質を抽出するためのもの。「モデルとは、知識が蒸留されたものだ」とエヴァンス本では説明されている。
*10:執筆作業時に匡剛さんが残していたメモ等が、パネルディスカッションの題材として提供された
*11:オブジェクト指向アプローチ。ソフトウェア設計および開発の方法論であり、オブジェクトと呼ばれるデータの単位を用いてシステムをモデル化する考え方。このアプローチでは、データとそれに関連する操作を一つの単位としてまとめることで、システムの設計や開発を行う。オブジェクト指向アプローチは、カプセル化、継承、多態性（ポリモーフィズム）といった特性を活用して、よりモジュール化され、再利用性の高いソフトウェアを構築することを目的としている。
*12:fat:膨れた。ソフトウェアにおいては、過剰な機能や複雑さをあらわす。高いリソース消費によりシステムのパフォーマンスが低下し、ユーザーエクスペリエンスが損なわれる可能性がある。
*13:訳者まえがきの記載：「その一方で、"DDD"というキーワードと断片的で偏った情報が一人歩きしていると感じることも少なくありません。ドメイン駆動設計の考え方を理解しないまま実装パターンを表面的に取り入れることにとどまっている現場や、部分的でゆがんだ情報を元にドメイン駆動設計に否定的な印象を持つ技術者を見かけることがあります」
*14:15章「蒸留」に書かれている
