はじめに
こんにちは、エンジニア2年目のはなまるです。
前回の記事で「完璧なDDDの世界なんてないから、泥臭く始めようぜ」ということを書きました。
今回も、オライリーの『ドメイン駆動設計をはじめよう』から学んだ実践的なアプローチについて書きます。
明日から実践できますよ!!!!!
テーマは「言葉の壁」と「部屋分け」 です。
1. 言葉の壁を取り払おう
DDDで一番有名で、一番使い倒されているワード。
それが「ユビキタス言語（チーム共通の言葉）」です。
要するに「開発メンバーとビジネス側（企画や営業）で言葉を合わせようね」ということなのですが、多くの現場ではこのような「すれ違い昼ドラ」が毎日上映されています。
ある日のミーティング:
ビジネス側: 「今回のキャンペーンでは、『お得意様』の画面にバッジを出したくて…」
エンジニア: （心の声：あーはいはい、『お得意様』ね。うちのDBだと、usersテーブルのis_premium = 1 のことだな。じゃあコードは User.isPremium()で実装しよ）
うまく回っているように見えますが、完全に破滅へのカウントダウンが始まっています。
数ヶ月後、悲劇が起きます。ビジネス側がこう言ってきました。
ビジネス側: 「『お得意様』の定義に、年間購入額も追加したくて〜」
エンジニア: 「あ、じゃあ『プレミアムユーザー』の条件変更ですね。フラグのロジック変えます」
ビジネス側: 「えっ？ プレミアムユーザー？ いや、私たちが話してるのは『お得意様』なんですけど…『お得意様』と『プレミアム会員』は別物ですよ？」
エンジニア: 「えっ…（同じだと思ってた…）」
お互いに「脳内翻訳」をしたまま会話を続けていたため、言葉の定義そのものがズレていたことが発覚します。
「エンジニア側の専門用語（または勝手に置き換えた言葉）」と「ビジネス側の言葉」が混ざり合うと、ミーティングのたびに「それってどの機能のことですか？」「あ、それはうちで言う〇〇です」という不毛な通訳フェーズが発生します。
これが、コミュニケーションコストと認識相違を生む最大の原因です。
実践のコツ: 普段の会話から「脳内翻訳」を挟まない
解決策はシンプルで、「エンジニアが勝手に言葉を言い換えず、ビジネス側と同じ言葉で会話する」ことです。
ビジネス側が「お得意様」と言ったらエンジニアも口頭やチャットで「お得意様」と呼ぶ。（勝手に「プレミアムユーザー」と言い換えない）
ビジネス側が「カートを空にする」と言ったら「クリア処理」ではなく「カートを空にする」と表現する。
わざわざ「今日からDDDをやります！」なんて大声で宣言する必要はありません。
ミーティングやチャットで相手が使っている言葉を注意深く拾い、そのままの言葉を使って会話を返す。
たったこれだけで、お互いの頭の中にあるイメージがバチッと噛み合い、「あの言葉ってどういう意味だっけ？」という不毛な認識合わせ会議が世界から消滅します。
とても嬉しいことですよね！
2. 言葉の部屋分けをしよう
言葉を統一しようとすると、次に必ずこのような壁にぶち当たります。
「人によって、同じ言葉を違う意味で使ってるんだけど！？」
例えば、「商品」という言葉。
- 販売チームにとっては「名前があって、価格があって、在庫があるもの」
- 配送チームにとっては「重さがあって、サイズがあって、届け先があるもの」
これを1つの巨大なProductクラスにまとめようとするから、プロパティが100個くらいある「神クラス」が爆誕します。
// 【悪い例：なんでもできる神クラス】
class Product {
private string id;
private int price; // 配送チーム「これ、配送の計算に要る？」
private float weight; // 販売チーム「これ、画面に出さないから邪魔なんだけど」
private int stock;
private string address; // もはや何がなんだか分からない
}
触るとどこが爆発するか分からないので、誰も触りたがらないパンドラの箱オブジェクトになります。
実践のコツ: 1つのシステムに同じ名前のクラスが複数あっていい
この本が教えてくれた解決策が、「境界づけられたコンテキスト（言葉の部屋分け）」です。
「販売コンテキスト」と「配送コンテキスト」をカッチリ分ければいい。
そして、それぞれの部屋に、それぞれのProductクラスがあっていいのです。
- 販売の部屋のProduct: id, price, stockだけを持つ。シンプル！
- 配送の部屋のProduct: id, weight, sizeだけを持つ。シンプル！
「1つのシステムで、同じ名前のクラスが2つあったらダメ（共通化しなきゃダメ）」という謎の固定観念を破壊しましょう！
まずは、社内で一番会話が噛み合っていなくて、コードがスパゲティになっている「あの言葉」を見つけて、部屋を2つに分けることから始めてみてください。
システム全体を一気に変える必要はありません！（←ココ重要！）
まとめ：言葉を合わせ、部屋を分けよう
今回は、DDDの核心である「ユビキタス言語」と「境界づけられたコンテキスト」を、少しずつ現場に投入しよう、というお話をしました。
難解な実装パターンを覚えるより、「ビジネスサイドと同じ言葉で話す」「意味がブレる言葉は部屋を分ける」。
これだけで、ソフトウェアの寿命は圧倒的に伸びます。
さっそく明日から、Let's try!!