はじめに

こんにちは、エンジニア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!!