Skip to main content
KISS TS版YAGNI TS版SoC TS版ADR TS版HC/LC TS版DRY TS版リファクタリング TS版テスタブル TS版TDD TS版エラーモデリング TS版レイヤー TS版MVC TS版依存関係ルール TS版DIP TS版DI TS版Is-a/Has-a TS版SOLID TS版GoFデザインパターン TS版Observer TS版CQS TS版状態機械 TS版不変条件 TS版Entity/VO TS版DDD TS版集約/境界 TS版ドメインイベント TS版モジュラーモノリス TS版ヘキサゴナル TS版クリーンアーキ TS版ACL TS版API Contract TS版SemVer TS版DbC TS版冪等性 TS版CAP定理 TS版Outbox TS版Saga TS版CQRS TS版イベントソーシング TS版BC TS版

第26章：Shared Kernel（共有コア）🧬⚠️

26.0 この章のゴール🎯✨​

この章が終わったら、次の3つができるようになります😊💪

  • Shared Kernel が「どんな関係」かを説明できる🗣️✨
  • 使っていい条件 / ダメな条件を見分けられる👀⚖️
  • “最小の共有” をTypeScriptで形にする方法がわかる📦🧩

26.1 Shared Kernelってなに？🧬🤝​

イメージ

Shared Kernel（共有コア）は、2つの境界づけられたコンテキスト（BC）が、ほんの一部のモデルやコードを「共同で」共有する関係です🧩✨ ポイントは「共有してるのに、BCは別のまま」というところ！

  • 片方が決めて片方が従う（Customer/Supplier）ではなくて、
  • 両方が“同じ共有物”を一緒にメンテする（対等）感じです🤝💞

Context Map のパターンとしても、Shared Kernel は代表的なものとして扱われます🗺️✨（BCは“相互関係を明示する”のが大事、という話にもつながるよ）(martinfowler.com)

26.2 文章でイメージ図🖍️📦➡️📦​

たとえば「取引（Trading）」と「配送（Shipping）」があって、お金（Money）や通貨（Currency）の表現だけは同じにしたい…みたいなとき👇

  • Trading と Shipping は別BC（別ルール・別責務）
  • でも「Money の形（通貨 + 金額）」だけは共通にしたい

こんな関係図になります😊

  • 📦 Trading BC ↔️ 🧬 Shared Kernel（Moneyなど最小） ↔️ 📦 Shipping BC

**共有物は“超ミニ”**じゃないと、後で地獄になります😇➡️😱 「小さく保て」「CIと自動テストが重要」みたいな注意点も、Shared Kernel の典型としてよく言われます。(vaadin.com)

26.3 どうして危ないの？（Shared Kernelの“副作用”）😵‍💫💥​

Shared Kernel は便利に見えるけど、結合（coupling）を増やすので危険です⚠️

起きがちな事故あるある🚑​

  • 共有物を変えるたびに「相手のBCが壊れる」💣
  • 「この変更いつマージする？」で調整会議が増える📅😇
  • 共有が増殖して、いつの間にか**“巨大共有モデル”**になる🌀
  • 結果：BCが別れてる意味が薄れて、実質ひとつの巨大BCみたいになる😵

だから、Shared Kernel は「いつでも使う万能技」じゃなくて、**“レア技”**と思ってね🧸✨

26.4 使っていい条件 / ダメな条件✅❌​

✅ 使っていい条件（だいたいこの4つ）​

  1. 共有したいものが“本当に小さい”（例：ID型、Money、通貨、日付範囲）✂️
  2. 両方のチーム（または担当）が共同所有できる🤝（勝手に変えない運用がある）
  3. 自動テスト＋CIが整ってる🧪🚦（壊したらすぐ気づける）
  4. 用語が安定してる📚（「同じ言葉の意味」がブレにくい）

❌ やめた方がいい条件（危険サイン🚨）​

  • 共有したいのが Entityや業務ルール（＝ドメインの中心）😱
  • 片方が外部ベンダー/外部サービスで、共同所有が無理🌧️
  • リリース周期が合わず、調整コストが高い🗓️💥
  • 共有物に「便利だから」機能が増え続けそう…🧟‍♀️

対等関係（Shared Kernel）に、ACLやPublished Languageなど“非対称前提のパターン”を混ぜると定義が矛盾しやすいよ、という整理もあります🧠🧩(Context Mapper)

26.5 「最小共有」って具体的に何を共有するの？✂️🧬​

結論：“語彙”と“値の表現”を共有して、業務ルールは共有しないが安全です😊🛡️

共有しやすい（✅おすすめ）​

  • IDの型（例：ListingId, UserId みたいな“識別子”）🏷️
  • Value Object（値オブジェクト）（例：Money、Email、DateRange）💎
  • ごく小さいenum（例：通貨コード、都道府県コードなど）🔤
  • “お約束”のエラーフォーマット（必要なら）🧾

共有しにくい（❌危険）​

  • Entity（例：User, Product）👤📦
  • **ユースケース（アプリ層）**🎮
  • RepositoryやDB都合のモデル🗄️
  • APIのDTO（BC間の運搬用はむしろ別にしたいことが多い）📦➡️📦

26.6 共有物の運用ルール（ここが本体）📜🤝🧪​

Shared Kernel は「コード」より「運用」が超大事です🧸✨ 最小限、これだけは決めよう👇

ルール1：共同所有（勝手に変えない）🤝​

  • 共有物の変更は 両BCのレビューを必須にする👀✅
  • 小さな変更でも「影響範囲」を一言で書く📝

ルール2：テストが先（CI必須）🧪🚦​

  • Shared Kernel には 単体テストを置く
  • 変更したら 両BCのテストが必ず走るようにする 「自動テストとCIがないShared Kernelは危険」って話は定番です💥(vaadin.com)

ルール3：ADRで“なぜ共有？”を残す🧾✨​

  • 「なぜShared Kernelにしたの？」「なぜここまで小さいの？」を短く記録📌 あとで“増殖”を止める武器になります⚔️

ルール4：バージョン方針（SemVer）を決める🔢📦​

  • 共有パッケージは **破壊的変更（breaking）**を強く意識する
  • “一緒に直せるからOK”って油断すると、突然全体が燃えます🔥😇

26.7 TypeScriptでの実装イメージ（モノレポ寄り）📁🧩​

イメージ

もしモノレポ（1つのプロジェクトの中に全BCが入ってる形）なら、

ここでは「共有を小さく保つ」ために、Shared Kernel を 独立パッケージとして作るよ😊 （モノレポ運用の代表例として、workspace構成を使うイメージ！）

Step 1：フォルダ構成を作る📁✨​

repo/
  packages/
    shared-kernel/
    trading/
    shipping/

Step 2：shared-kernel に“共有していいものだけ”置く✂️🧬​

例：Money（通貨 + 金額）だけ共有する💰

// packages/shared-kernel/src/money.ts
export type Currency = "JPY" | "USD";

export class Money {
  private constructor(
    public readonly amount: number,
    public readonly currency: Currency
  ) {}

  static of(amount: number, currency: Currency): Money {
    if (!Number.isFinite(amount)) throw new Error("amount must be finite");
    if (amount < 0) throw new Error("amount must be >= 0");
    return new Money(amount, currency);
  }

  add(other: Money): Money {
    if (this.currency !== other.currency) {
      throw new Error("currency mismatch");
    }
    return Money.of(this.amount + other.amount, this.currency);
  }
}

✅ ここでの狙い：

  • “お金の表現”は共通でOK
  • でも「手数料計算」や「割引ルール」は共有しない（各BCのルール）🙅‍♀️

Step 3：Trading / Shipping 側で使う📦➡️💰​

// packages/trading/src/checkout.ts
import { Money } from "@repo/shared-kernel/money";

export function calcTotal(): Money {
  const item = Money.of(1200, "JPY");
  const fee = Money.of(200, "JPY");
  return item.add(fee);
}

Step 4：共有を増殖させない“禁止ルール”を文章化🛡️📜​

PRテンプレやチェックリストに入れると最強💪✨ 例：

  • Shared Kernel に Entityを追加しない
  • Shared Kernel に ユースケースを追加しない
  • “便利関数”を生やしたくなったら、まず 各BCに置けないか考える

26.8 AI相棒に聞くテンプレ🤖💬（コピペOK）​

① 共有候補を“最小”に絞る🧠✂️​

  • 「Trading と Shipping の間で共有したい概念を列挙して。次に“Shared Kernelに入れてよい/ダメ”を分類して。基準も説明して。」

② “増殖リスク”をレビューしてもらう🧟‍♀️🚫​

  • 「このshared-kernelに追加しようとしている型/関数が、境界を壊すリスクを指摘して。代替案（各BC側に置く、DTOにする等）も出して。」

③ 破壊的変更チェック🔍💥​

  • 「この変更は breaking change？ 影響を受ける側の修正点を具体的にリスト化して。」

26.9 最終チェックリスト✅🧾（Shared Kernelを守る呪文🪄）​

  • 共有してるのは 値の表現（VO/ID）中心？💎
  • 共有物は 小さく保ててる？（“便利だから追加”が増えてない？）✂️
  • 変更は 両BCレビュー必須になってる？👀
  • CIで 両BCのテストが走る？🧪🚦
  • “なぜ共有？”が ADRで残ってる？🧾
  • 共有が増えすぎたら、**BC統合/別パターン（ACL等）**を検討する準備ある？🧠

26.10 ミニ補足：TypeScriptの最近（2026/02/02時点）🧸💻​

  • TypeScript の安定版ラインは 5.9.3 が latestとして配布されています。(npm)
  • 5.9 では --module node20 のような安定オプションも整理されていて、設定の“ふらつき”を減らす方向が見えます。(TypeScript)
  • さらに高速化の流れとして **ネイティブプレビュー（@typescript/native-preview）**が提供されていて、エディタ統合も進捗が出ています🚀(Microsoft for Developers)

（Shared Kernel は「共有物のCIが重くなる」と破綻しやすいので、ビルド/型チェック高速化の流れは相性がいいよ😊⚡）