TRACERYプロダクトマネージャーの haru です。
2024年8月29日(木)に開催された勉強会「BPStudy#204〜ドメイン駆動設計をはじめよう」では、書籍ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法（以降、LDDD*1）の翻訳者とレビュアーをお招きし、パネルディスカッションを実施しました。その時の様子をお伝えします。翻訳者とレビュアーの見解を通じて、書籍をより深く理解し、実践に役立つヒントを得られるでしょう。
- その１: 書籍の魅力と翻訳の舞台裏
- その２: エヴァンス本との相違点
- その３: 「同じ言葉」を日本語で運用するノウハウ
- その４: 重要なツールとして進化した、区切られた文脈 (本記事)
パネルディスカッション参加者
- パネラー：
- 増田 亨(ますだ とおる) 氏(翻訳者：以下、増田)
- 綿引 琢磨(わたびき たくま) 氏(翻訳者：以下、綿引)
- 佐藤 匡剛(さとう ただよし) 氏(レビュアー：以下、匡剛)
- モデレータ：
- haru(本記事の執筆者)
区切られた文脈の設計のコツ
同じ言葉の一貫性に注目することで、その言葉が通用するもっとも広い範囲を特定できます。（p.44）
業務領域は「発見」であり、区切られた文脈は「設計」です。（p.49）
3章 事業活動の複雑さに立ち向かうより
haru：「区切られた文脈は設計なので、開発チームが決めて良い」と書籍には書かれています。業務領域と区切られた文脈の関係はどのように考えればよいでしょうか。区切られた文脈を設計するコツや考え方について教えてください。
匡剛：3章「事業活動の複雑さに立ち向かう」の「業務領域」、「区切られた文脈」、「同じ言葉」の3つの関係を理解することが、ドメイン駆動設計そのものを理解するうえで重要ですし、その点で3章をしっかり読み込むことが大事ですね。
区切られた文脈の設計の考え方として、3章で言われているのは「区切られた文脈の最大サイズの範囲を同じ言葉に注目することで発見できますよ」ということです。区切られた文脈の範囲をそれ以上大きくすると「同じ言葉」が破綻するような場合は、区切られた文脈の範囲をそれ以上大きくできませんということです。そして、それは開発チームの裁量で決定してよいということです。
さらに言っているのは、「区切られた文脈」は、チームのオーナーシップと関係していて、複数のチームで1つの「区切られた文脈」を担当してはいけないということです。チームの構成と「区切られた文脈」が対応しているという関係です。チーム設計、組織設計の話になります。一方で業務領域は、事業、業務そのものの中で決まっているもので、エンジニアがどうこうできるものではなく既にあるものという意味で「発見」なんですよね。どの業務領域をどのように分担するかを決めていくと、自然と「業務領域」と「区切られた文脈」の設計が決まってくると思います。
ドメイン駆動設計の重要なツールとして進化した「区切られた文脈」
増田：3章は明快に書かれていて参考になりますよね。匡剛さんの仰ったとおり、「区切られた文脈」は「同じ言葉」が通じる範囲であり、チームの単位であり、モデルの一貫性が維持できる範囲である、ということがくり返し説明されています。
同じ業務領域でも、担当者から見えるモデルと、管理者から見えるモデルは当然違っていて、別のアプリケーションになる可能性が充分あります。管理者用のアプリケーションをつくるチームと、担当者用のアプリケーションをつくるチームが別々に「区切られた文脈」で1つの「業務領域」を担当するということが可能性としてはあるわけです。
言葉が違って、チームが違って、モデルも違う。何のために区切るのかという「Why」と、何を手がかりとして区切るのかを考えるときに、「同じ言葉」「チーム」「モデル」で区切るんですよ、という「How」が、3章で説明されています。
逆に業務が複雑ではなくて、一貫性を持って取り扱えるのであれば、文脈を区切る必要は無いわけですね。なぜ文脈を区切るのかといえば、2つのチームが1つの文脈をごちゃごちゃやりだしたら混乱しますよねとか、同じ言葉が異なる意味になったら混乱するよねとか、ということです。
文脈の区切り方について、特に私が一番感銘を受けたのが「それ以上、範囲を大きくしたら破綻してしまうという範囲でまず区切って、知識が深まってきたら複雑さも見えてくるから、そこで必要だったらさらに区切っていきましょう」という段階的な文脈の区切り方の話が、非常に参考になりました。
haru：時間軸で考えるアプローチについては、LDDDの他の部分でもさまざまに述べられていますね。例えば、第10章「設計の経験則」や付録A「ドメイン駆動設計の実践：事例研究」などです。
増田：マイクロサービスの区切り方（14章「マイクロサービス」）もですね。「（以降、エヴァンス本*2）が出版された時代(2003年)から進んで、「区切られた文脈」は、もっと重要なツールとして、進化したというイメージがあります。
haru：第4章「区切られた文脈どうしの連係」では、区切られた文脈同士をどのように連係させるかについて、いくつかの図を用いて説明されています。
増田：第3章「事業活動の複雑さに立ち向かう」や第4章「区切られた文脈どうしの連係」では、従来のドメイン駆動設計の書籍では、説明が曖昧であったり、効果についての記述がなかった点が、LDDDでは明確かつ具体的に説明されています。
haru：区切られた文脈の設計がうまくいかないと、ドメイン駆動設計による開発も危なくなります。土台となる戦略的設計を開発チームのメンバーが理解して初めて、成功の可能性が高まると思います。
綿引：マイクロサービスであるかどうかに関わらず、「区切られた文脈」はソフトウェアのリリースやデプロイの単位と重なるという側面があります。
haru：一枚岩のシステムでは、あるチームがソフトウェアの最新版をデプロイすると、他のチームのソフトウェアにも影響を及ぼすリスクが高まりますからね。
増田：「1つのチームが複数の文脈を扱っている場合、区切りがぼやけることがあるので注意が必要」とLDDDに書かれていて、これは重要だと思いました。文脈を区切ったつもりでも、複数の文脈を同じチームが担当すると、境界線が曖昧になり、次第に混ざってしまうことがあります。1つのチームが区切られた文脈を担当する際には、意識的に境界を明確にするように心がけるべきだと書かれていて、なるほどと感じました。
haru：そこは、区切られた文脈についての正しい理解と、明確に分けるという意志がないと、次第に混ざってしまう力が働きますね。
増田：よしなにつなげてしまうというかね。
綿引：これでいけるじゃんみたいな。
haru：その逆のアンチパターンとして「分散した泥団子*3」というのも書かれていますよね（14章「マイクロサービス」）
増田：本当に実践的ですよね。
訳者とレビュアーから最後にひとこと
haru：あっという間に終わりの時間になりました。みなさん最後にひとことずつ頂けますか。
増田：このメンバーで話せて楽しかったです。気づきがありました。綿引さんに（イベントの第2部で「ドメイン駆動設計のコミュニティで現在活発なコミュニティが無さそう」と）煽られた*4ので、勉強会の方も考えて企画したいと思います。輪読会するとか。コミュニティ重要ですね。
haru：綿引さんの話は、久々に「エンジニアとは」というテーマで良い話を聞いたなと思いました。
綿引：今回の翻訳は、良い機会をいただけたなという感想です。翻訳後にイベントを開催してもらったりもですね。また機会があればいろいろやってみたいとおもいます。
haru：BPStudyも2回目の登壇ありがとうございます。
匡剛：出版されてから訳者のお2人と話す機会がなかったので良かったなと思います。
haru：Xでの方が活発なんですかね(笑)
増田：打ち上げもやりましょう（笑）
匡剛：この書籍は戦略的設計のところから入っているので、区切られた文脈やその関係などについて、ネット上などで議論されると良いかなと思っています。
haru：本日は登壇いただきありがとうございました。
*1:原書のタイトルは "Learning Domain-Driven Design"
*2:エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう。ドメイン駆動設計の原典として広く認知されている。
*3:文脈を小さく区切りすぎてしまい、保守や開発のコストしにくくなる現象
*4:イベントの第2部の登壇資料:ドメイン駆動設計を実践するために必要なもの
*5:イベントの第2部の登壇資料:『ドメイン駆動設計をはじめよう』中核の業務領域
*6:イベントの第2部の登壇資料:ドメイン駆動設計を実践するために必要なもの
