Skip to main content
KISS C#版YAGNI C#版SoC C#版ADR C#版HC/LC C#版DRY C#版Refactoring C#版テスト容易な設計 C#版TDD C#版エラーモデリング C#版レイヤー C#版MVC C#版依存関係ルール C#版DIP C#版DI C#版Is-a/Has-a C#版SOLID C#版GoF C#版Observer C#版CQS C#版状態機械 C#版不変条件 C#版Entity/VO C#版DDD C#版集約と境界 C#版ドメインイベント C#版モジュラーモノリス C#版ヘキサゴナル C#版クリーンアーキ C#版ACL C#版API Contract CSSemVer C#版DbC C#版冪等性 C#版CAPの肌感覚 C#版Outbox C#版Saga C#版CQRS C#版ES C#版境界づけられたコンテキスト C#版

第16章：ズレ探しA「同じ単語・意味が違う」🧨

この章のゴール🎯✨​

  • 「同じ単語なのに、意味が違う」ポイントを見つけられるようになる🔍📝
  • 見つけたズレを、**“衝突メモ”**にして整理できるようになる📒✨
  • そのズレが「境界（Bounded Context）」のヒントになる感覚をつかむ🗺️💡 （Bounded Contextは“その中では言葉の意味が一貫する範囲”だよ〜、という話につながるよ✅） (vaadin.com)

1) まず「同名異義」ってなに？🤔🌀​

同名異義＝同じ単語なのに、部署/目的/タイミングで意味が変わることだよ🙋‍♀️✨ たとえば「顧客」「注文」「金額」「住所」…ぜんぶ事故りやすい単語たち💥

DDDでは、こういう“言葉のあいまいさ”を放置すると、コードがすぐ壊れやすくなるから、 **「その言葉が通じる範囲（＝境界）をはっきりさせよう」**って考えるよ🧠🔒 (vaadin.com)

2) ミニECでよくある「同じ単語・意味ちがう」例🛒💥​

例A：「顧客（Customer）」が3人いる👤👤👤​

同じ単語で意味が違う

  • 受注の文脈：会員（注文した人）
  • 請求の文脈：支払い責任者（請求先）
  • 配送の文脈：受取人（届け先）

📌ここで「Customerを1つのクラスに全部詰める」と…

  • Customer.Address ← え、**配送先？請求先？**😵‍💫
  • Customer.Name ← え、**会員名？受取人名？**😇
  • ルールも分岐だらけ：if (用途 == 請求) ... else if (用途 == 配送) ... 💣

例B：「注文（Order）」が部署で別物📦🌀​

  • 受注：カート→確定→キャンセルを扱う「注文」
  • 配送：梱包単位・送り状が主役の「注文」
  • 請求：請求書・入金・締めが主役の「注文」

同じ“Order”でも、見てる世界が違うんだよね👀✨ (vaadin.com)

3) ズレを見つける「3ステップ」🔍➡️📝➡️🗺️​

ステップ①：怪しい単語リストを作る📝🚨​

イベントストーミングのイベント（過去形）を眺めて、 名詞を抜き出すよ✂️✨

例：

  • 注文が確定した📦
  • 支払いが確定した💳
  • 出荷が確定した🚚
  • 住所が登録された🏠
  • 返金が確定した💸

ここから「注文」「支払い」「住所」「金額」「顧客」みたいな単語を候補にする🎯

ステップ②：その単語を「誰の視点？」で分解する👀🧩​

同じ単語でも、視点が変わると意味がズレるよ！

単語ごとに、この3問を当てると超強い💪✨

  1. 誰がその単語を使う？（部署/役割）👤
  2. 何を決めるために使う？（判断/責任）⚖️
  3. いつ使う？（どのイベントの前後？）⏳

✅この3つが違うなら、意味が別物の可能性が高い！

ステップ③：「衝突メモ」にして固定する📒🔒​

見つけたズレは、**“メモ化して固定”**が大事！ 頭の中に置くと、だいたい忘れて混ざる😇

4) 衝突メモのテンプレ📝✨（この章の主役）​

下のテンプレをコピって、単語ごとに埋めるだけでOK👌💕

衝突メモ（テンプレ）

  • 対象単語：＿＿＿＿

  • 意味A（文脈/視点）：＿＿＿＿

    • 使う人：＿＿＿＿
    • 代表イベント：＿＿＿＿
    • 重要ルール：＿＿＿＿

  • 意味B（文脈/視点）：＿＿＿＿

    • 使う人：＿＿＿＿
    • 代表イベント：＿＿＿＿
    • 重要ルール：＿＿＿＿

  • 似てるデータ：＿＿＿＿（例：住所、金額）

  • 決定：

    • ☐ 同じ単語のまま（用語統一する）
    • ☐ 別名にする（例：ShippingAddress / BillingAddress）
    • ☐ 境界を分ける候補（BC候補：＿＿＿＿ / ＿＿＿＿）

📌「ユビキタス言語はBounded Contextの中で育てる」ので、こういうメモが効いてくるよ📚✨ (GitHub)

5) “図（文章で）”でズレを可視化しよう🗺️✍️​

例：「住所」🏠が混ざってるケース

  • 【受注】住所＝**届け先住所（配送のため）**📦🚚
  • 【請求】住所＝**請求先住所（請求書のため）**💳🧾

文章図にすると、こう👇

  • 受注の会話： 「この住所に商品を届けたい」
  • 請求の会話： 「この住所に請求書を送りたい」

同じ「住所」でも、目的（責任）が違う＝ズレのサイン🚨✨

6) ミニ演習①🧩📝（ズレ探しウォーミングアップ）​

次のイベントから「同じ単語・意味が違いそう」な単語を3つ選んで、衝突メモを書こう💪✨

  • 注文が確定した📦
  • 送料が計算された🧮
  • 請求書が発行された🧾
  • 出荷が確定した🚚
  • 住所が更新された🏠
  • 返金が確定した💸

解答例（1つだけ）✅​

  • 対象単語：住所
  • 意味A：配送先住所（出荷のため）🚚
  • 意味B：請求先住所（請求書のため）🧾
  • 決定：別名にする（ShippingAddress / BillingAddress）＋境界の候補にもなる🗺️✨

7) ミニ演習②🧠⚖️（“境界候補”まで進める）​

「顧客（Customer）」が衝突してるとき、次のうちどれが良さそう？（理由も1行で）

A. Customerを1つにしてプロパティ増やす📦 B. 名前を分ける（Member / BillTo / ShipTo）🏷️ C. “顧客”という単語を禁止する🚫

解答の方向性✅​

  • だいたい Bがスタートとして強い💪✨ 同じ単語を無理やり統一すると、ルールが混ざって壊れやすいからだよ💥 （“境界の中では言葉の意味が一貫してる”状態に寄せたい） (vaadin.com)

8) C#で「同名異義を分ける」超ミニ実装💻🔒​

ポイントはこれ👇

  • 同じ“Customer”でも別namespace（＝別コンテキスト側）に置く📁✨
  • 境界を越えるときは **DTO（契約の形）**にして渡す📨
// ✅ 受注側（OrderManagement）の「Customer」＝会員
namespace Shop.OrderManagement.Domain;

public readonly record struct MemberId(string Value);

public sealed record ShippingAddress(
    string PostalCode,
    string Prefecture,
    string City,
    string Street
);

public sealed record Order(
    string OrderId,
    MemberId Buyer,              // 注文した会員
    ShippingAddress ShipTo,      // 届け先（配送のため）
    decimal OrderTotal
);
// ✅ 請求側（Billing）の「Customer」＝請求先（支払い責任）
namespace Shop.Billing.Domain;

public readonly record struct BillingAccountId(string Value);

public sealed record BillingAddress(
    string PostalCode,
    string Prefecture,
    string City,
    string Street
);

public sealed record Invoice(
    string InvoiceId,
    BillingAccountId BillTo,     // 支払い責任者
    BillingAddress BillingTo,    // 請求先住所
    decimal InvoiceAmount
);
// ✅ 境界を越えるときのDTO（Published Languageの“入口”っぽいもの）📨
namespace Shop.Contracts;

public sealed record OrderPlacedDto(
    string OrderId,
    string BuyerMemberId,
    string ShipToPostalCode,
    decimal OrderTotal
);

「同じCustomerを共有しない」っていうだけで、混乱が激減するよ😊✨ （C# 13 は .NET 9 SDK と最新の Visual Studio 2022 で試せるよ。） (Microsoft Learn)

9) つまずきポイント集🧯😵‍💫​

  • 「同じ単語なんだから統一すべき！」と思いがち → でも、意味が違うなら統一すると事故る💥（用語統一より“境界分離/別名”が先のことも多い）
  • DBの列が同じだから同じ意味、と勘違い → データ形が似てても、責任（ルール）が違うと別物📦⚡
  • 「あとで整理する」って保留し続ける → まず衝突メモにして“見える化”しよう👀📝（保留でもOK、放置がNG🙅‍♀️）

10) 今日のチェックリスト✅✨（提出前に見るやつ）​

  • 同じ単語が、イベントの別の場所で出てくる？🔁
  • その単語で、**決めてること（判断/責任）**が違う？⚖️
  • その単語の“正しい形”が、部署で揉めそう？😇
  • 「別名にした方が会話が速い」感じがある？🚀
  • 衝突メモに書いた？📒✅

11) お助けAIプロンプト🤖✨（この章専用）​

  • 「次のイベント一覧から、同じ単語で意味が変わっていそうな候補を10個出して。候補ごとに“別の意味”を2案ずつ書いて」🔍📝
  • 「この文章中の“顧客/注文/住所/金額”が、文脈によって何を指すか分類して（受注/請求/配送）」🧩👀
  • 「“衝突メモ”をこのテンプレで埋めて：対象単語/意味A/意味B/代表イベント/重要ルール/決定」📒✅
  • 「Customerを1つにまとめた設計が生む問題を、具体例（プロパティ・if・テスト）で説明して」💥🧪
  • 「別名にするなら命名案を5つ（Member/BillTo/ShipToなど）＋メリットも添えて」🏷️✨