前置き
上記の記事の続きです。
ドメイン駆動設計では、明確に「コアドメイン」それを支える「サブドメイン」などというように、境界を定義することが重要です。
このDDDで定義される境界は、単なるコードの整理術ではありません。
これは、ビジネス価値の分布図そのものであるため、
「どこにテストコストという名の『保険』を重点的にかけるべきか？」（戦略）
そして
「その保険はどのような種類（テスト手法）であるべきか？」（戦術）
を示す、強力なテスト戦略マップとして機能します。
DDDの境界が導くテスト戦略
DDDにおけるドメインの分類は、そのままテストの優先順位と手法の選択に直結します。
👑 コアドメイン (Core Domain)
ここはビジネスの競争優位性が生まれる場所であり、最も複雑で、最も変更が頻繁に起こる領域です。（図の「中核」領域）
テストコストをかけるべき理由
・最高のビジネスリスク
ここのバグは、事業の失敗や信用の失墜に直結します。
・最高の複雑性
独自のビジネスルールが凝縮されており、バグが潜む可能性が最も高いです。
・最高の変更頻度
ビジネスの成長と共に、常に進化し続けるため、リファクタリングが頻繁に発生します。
実践すべきテスト
・単体テスト / ドメインモデルテスト
最も重点的に投資すべき領域です。
データベースやUIといった外部依存を完全に排除し、複雑なビジネスロジックそのものを高速かつ徹底的に検証します。 これにより、安全なリファクタリングが可能になります。
・高カバレッジの維持
コードカバレッジは、この領域では特に重要な指標となります。
複雑なロジックの組み合わせが網羅的にテストされていることを保証しないといけません。
・プロパティベーステスト
不変条件（常に守られるべきルール）を、多様なデータパターンで自動的に検証するのに非常に有効です。
🛠️ 補完サブドメイン (Supporting Subdomain)
コアドメインを支えるために必要な、自社で開発するが差別化要因ではないドメインです。
（図の青い「補完」領域）
テストコストをかけるべき理由
・中程度のビジネスリスク
これが機能しないと、コアドメインが正しく動作しません。
・中程度の複雑性
コアドメインほどではないが、独自のロジックを含みます。
実践すべきテスト
・コンポーネントテスト / 統合テスト
単体テストもたしかに重要ですが、
このドメインがコアドメインや他のドメインと正しく連携できるか
を検証するテストの比重が、自ずと大きくなります。
・シナリオベースのテスト
特定の業務フローに沿って、コンポーネントが期待通りに振る舞うかを確認します。
🧩 一般サブドメイン (Generic Subdomain)
認証や決済など、すでに「解決済みの問題」であり、外部ライブラリやSaaSを利用することが多い領域です。
テストコストをかけるべき理由
・限定的なリスク
リスクは、
外部サービスのロジックそのものではなく、「我々がそれを正しく使えているか」 という点に集中します。
外部サービスの内部で持つリスクに関しては、自分たちではコントロールできない定数扱いのリスクだからです。
実践すべきテスト
・インテグレーションテスト / 契約テスト
外部サービスのAPIを、我々のコードが仕様通りに呼び出せているか、そしてレスポンスを正しく解釈できているかを検証します。
・アダプタの単体テスト
外部サービスとの境界に位置する自分たちのコード（アダプタやラッパー）に限定してテストします。外部サービスそのものをテストする必要はありません。
まとめ：境界がもたらす合理的判断
このように、DDDの境界はテスト戦略に以下のような合理性をもたらします。
DDDの境界を意識することで、テスト活動は
「すべてのコードを均一にテストする」という非効率なもの
から、
「ビジネス価値とリスクに応じて、テストの投資対効果（ROI）を最大化する」
という、極めて戦略的な活動へと昇華されます。
境界の曖昧さを洗練していく過程でのテスト戦略の変化
ただその際に、境界位置がはっきりしないことも多々あります。
（最初から、明確に境界を定義できたらいいんですけども、、、）
そこでモデリングで「コンテキストマップ」を描くことにより、大枠でもいいからコアドメインと支援サブドメイン、汎用サブドメインとの境目を定義することが重要です。
「細かい範囲で言ったら間違っているかもしれないけども、大枠で言ったらほぼ間違いなくここで境界引けるよね」という部分を見つけるんです。
たとえば、汎用サブドメインは外部サービスを使うことにより、明確に他の部分と境界を引くことができます。（外部サービスとイベント駆動で連携し合う）
しかし問題は、
コアドメインと支援サブドメインという自分たちで実装する必要のある２つの領域の境界です。
DDDの境界、特にコアドメインと支援サブドメインの境界は、最初から完璧に引けるものではありません。
ココはむしろ、設計と運用を通じて 「発見」していくもの です。
そして、その発見のプロセスこそが、テスト戦略を最適化するための最も信頼できる羅針盤となります。
1. コンテキストマップ：境界の「初期仮説」を立てる
最初のステップとしてコンテキストマップを描くことは極めて重要です。
目的
完璧な境界を引くことではなく（てか初期からは無理です）、
「現時点での我々の理解では、ここが境界であるだろう」という合意形成可能な仮説を立てる
ことです。
効果
大枠でもいいので境界を引くことで、チームは
「ここは重要だから手厚くやろう（コアドメイン）」
「ここは外部連携が肝だから契約テストを重点的にしよう（汎用サブドメイン）」
といった、初期のテスト方針を立てることができます。
2. 境界の明確化：運用データという「動かぬ証拠」
問題は、自分たちで実装するコアドメインと支援サブドメインの間の、曖昧な境界です。
この境界は、以下の運用データを監視することで、時間と共にはるかに明確になります。
📈 変更頻度
あるビジネス要件の変更が、常にモジュールAとモジュールBの両方に修正を要求する場合、
それらは思った以上に密接であり、同じドメイン（おそらくはコアドメイン）に属している可能性が非常に高いです。
🐞 障害・バグの発生箇所
ビジネスインパクトの大きな障害が、特定のモジュールに集中している場合、そこはチームが思っている以上に「コア」な役割を担っている証拠です。
🗣️ チーム間のコミュニケーション
チームAが何かを変更するたびに、必ずチームBとの調整会議が発生する場合、その2チームが担当するドメインの境界は、おそらく見直す必要があります（コンウェイの法則）。
3. 境界の明確化がもたらすテスト戦略の最適化
そして、この境界の明確化は、テストリソースの再配分を促す強力なトリガーとなります。
境界が明確になるほど、それに伴って
・「本来はよりテストコストをかけるべきであったが、足りていなかった部分」
・「本来はより少ないテストコストでよかったが、過剰にテストコストをかけてしまっていた部分」
が、より明確になってきます。
これは、テスト戦略における「勘」や「慣習」を排除し、データに基づいた合理的な意思決定を可能にしてくれます。
明らかになる「テスト不足」の領域
症状
「ここは単純な支援サブドメインだと思っていたが、実際には毎週のように仕様変更が入り、重要なバグが多発している。
単体テストがほとんどなく、毎回E2Eテストで問題が発覚して手戻りが大きい。」
処方箋
この領域は、実質的なコアドメインであったと認識を改めます。
そして、カバレッジの高い単体テストを集中的に書き、リファクタリングを支えるセーフティネットを構築するためにテストコストを追加投資します。
明らかになる「テスト過剰」の領域
症状
「このモジュールはコアドメインの一部だと考えていたため、単体テストカバレッジ90%を維持している。
しかし過去1年間、仕様変更は一度もなく、バグも発生していない。テストの維持コストだけがかかっている。」
処方箋
この領域は、安定した支援サブドメインであったと判断します。
単体テストの実行頻度を下げたり、一部をより大きな粒度のコンポーネントテストに統合したりすることで、テストコストを削減します。
そして、そこで浮いたリソースを、本当にリスクが高い領域に再投資します。
まとめ
このプロセスは、アーキテクチャとテスト戦略が一体となって、ビジネスの変化に適応し、進化していく動的なフィードバックループそのものです。
DDDの境界モデリングは、このループを回し始めるための、最初の最も重要な一歩です。
一度定義して終わりではなく、スプリントレビューの時に、必ず見直すことを習慣化しましょう。