TRACERYプロダクトマネージャーの haru です。
2024年8月29日(木)に開催された勉強会「BPStudy#204〜ドメイン駆動設計をはじめよう」では、書籍ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法（以降、LDDD*1）の翻訳者とレビュアーをお招きし、パネルディスカッションを実施しました。その時の様子をお伝えします。翻訳者とレビュアーの見解を通じて、書籍をより深く理解し、実践に役立つヒントを得られるでしょう。
- その１: 書籍の魅力と翻訳の舞台裏
- その２: エヴァンス本との相違点
- その３: 「同じ言葉」を日本語で運用するノウハウ (本記事)
- その４: 重要なツールとして進化した、区切られた文脈
パネルディスカッション参加者
- パネラー：
- 増田 亨(ますだ とおる) 氏(翻訳者：以下、増田)
- 綿引 琢磨(わたびき たくま) 氏(翻訳者：以下、綿引)
- 佐藤 匡剛(さとう ただよし) 氏(レビュアー：以下、匡剛)
- モデレータ：
- haru(本記事の執筆者)
変数とメソッド名は日本語、クラス名は英語という取り組み
私は、少なくとも、事業活動で関心の対象となるエンティティ名は、英語の名前を使うことをすすめています。（p.36）
2章 業務知識を発見する
haru：「同じ言葉」について、普段どのように運用していますか。
綿引：基本的に英語にしています。enumは日本語を使うことが多いです。ソースコードはほぼ英語にしています。
haru：日頃の会話はいかがですか。
綿引：日頃の会話とソースコードを合わせるといった意味でいうと、「同じ言葉」を使っていないということになるんですけども、会話は日本語でソースコードは英語でという感じです。
増田：「同じ言葉」の趣旨は、関係者で意図を伝えるために使いましょうということだと思います。ソースコードが英語かどうかというのは副次的な課題です。関係者間で日本語で業務の言葉を伝えあってることができていて、日本語の業務知識も増えても、エンジニアがその業務知識をソースコードで英語にするところで課題になるわけです。
ソースコードで日本語を扱うということについて、全て日本語でやってみたりとか、アクティアの高崎さん*2ともディスカッションしてきて、今のところ落ち着いているのは、ドメインモデルのクラスにおいては変数名とメソッド名は全部日本語、クラス名（型名）は英語というところです。
それを実践したときに気づいたのですが、業務エキスパート*3と話してるときは、基本的にクラスではなくてオブジェクトの話をしているんですよね。
その話した内容をソースコードにするときに、変数はオブジェクトを指しているので、変数名とメソッド名（「変数名.メソッド名」)が日本語になっているだけで、「同じ言葉」とソースコードがつながっている感覚が出てきます。そして、むしろクラス名は英語のままのほうが良いのではないかというのが今の感覚です。
あと、日本語を使うことで効果的だと思うのは、DBのテーブル名、カラム名を全部日本語にすることです。これは業務の知識を扱う中で良い効果が生まれると思っています。
haru：DBのカラム名は日本語が英語表記されていることがあって、わかりにくいことがありますね。
増田：怪しげなローマ字とかね。KBNで区分とかですね(笑)。
同じ言葉の日本語の取り組みは、日本語を使っている人が考えよう
匡剛：同じ言葉の話は、日本でドメイン駆動設計を実践するうえで、一番ハードルになるところかなとは思っています。著者の「同じ言葉では英語を使いましょう」といっているのは、行き過ぎと言うか、アジア圏のことはあまり分かってないのではと思います。
増田：経験してないので、意識はしてないでしょうね。
綿引：エヴァンスさんが2011年に来日した時に、似た質問をしたことがあります。当時携わっていた開発案件が、ドメイン駆動設計でやるぞ、という案件だったんですが、使っている業務の言葉で長い日本語があったんですよ。それを英語の単語でつなげるとクラス名が80文字くらいになってしまって（笑）。インスタンスをnewするだけでコードが改行してしまうみたいな、読みづらいコードでした。エヴァンスさんに「どうしたらよいとおもいます？」と聞いたら、「なんで日本語使わないんだ」という回答でした。Javaだったら日本語使えるよねと。
そうは言われたものの、増田さんの話を聞いてなるほどと思ったのですが、クラス名を日本語にしようとすると、大文字小文字が使えないので、クラスで使う単語の区切りが難しいですね。
増田：日本でどうするかって話を日本語を知らないエヴァンスに聞いてもしょうがないですね（笑）エキスパートじゃないので。日本のエンジニアが良いやり方を探しに行かないと。
haru：「同じ言葉」は、開発において本当に大事だなとおもってるんですが、油断するとすぐに言葉がぶれるんですよね。複数人で開発してるいつの間にかぶれていることに気づいて、直すか直さないかで、妥協すると影響範囲と修正工数が大きいから直さないことになりがちです。一方で「同じ言葉」という観点で考えると、大変でも直そうという判断になります。第2部の綿引さんの話で、同士*4という話がありましたけど、「同じ言葉」という意識をチーム内で持ち、意志を高めるのはとても大事だなと思います。それがシステムの長期的な発展性につながり、ひいては事業の発展に貢献することになると思います。
次回の、重要なツールとして進化した、区切られた文脈〜「ドメイン駆動設計をはじめよう」翻訳者・レビュアー対談その4 - TRACERY Lab.（トレラボ）では、「区切られた文脈」を設計する考え方についてお伝えします。
*1:原書のタイトルは "Learning Domain-Driven Design"
*3:特定のビジネス領域や業務分野に深い知識と経験を持つ専門家のこと。ドメインエキスパートは、その分野における業務プロセス、ルール、制約、ビジネス上の目標などについて理解しており、ソフトウェア開発チームと協力して、システムがビジネスのニーズに適合するようにする役割を担う。
*4:イベントの第2部の登壇資料:ドメイン駆動設計を実践するために必要なもの
