document

ドキュメント

モジュール性レビューの最終ドキュメントを、Markdown（.md）と HTML（.html）の 2 つの形式で作成します。両方のファイルの内容は同一です。

ドキュメントの構成

ヘッダー

# Modularity Review

**Scope**: [what was analyzed]
**Date**: [date]

エグゼクティブサマリー

以下を網羅する、3～5 文の短い段落です。

• プロジェクトの機能（中核となる機能）
• 全体的なモジュール性の状態（健全、要注意、重大な問題）
• レビューで最も重要な指摘事項

結合の概要表

主な連携をすべてまとめます。表のヘッダーには必ず coupling.dev へのリンクを設定してください。

| Integration | [Strength](https://coupling.dev/posts/dimensions-of-coupling/integration-strength/) | [Distance](https://coupling.dev/posts/dimensions-of-coupling/distance/) | [Volatility](https://coupling.dev/posts/dimensions-of-coupling/volatility/) | [Balanced?](https://coupling.dev/posts/core-concepts/balance/) |
| ----------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------- |
| A -> B      | ...                                                                                 | ...                                                                     | ...                                                                         | ...                                                            |

問題

特定した不均衡ごとに、セクションを作成します。

## Issue: [Short descriptive title]

**Integration**: [Component A] -> [Component B]
**Severity**: [Critical / Significant / Minor]

### Knowledge Leakage

What knowledge is shared that shouldn't be, or is shared implicitly when it should be explicit. Identify the specific implementation details, business rules, or domain model concepts that leak across the boundary.

### Complexity Impact

How this imbalance makes change outcomes unpredictable. What happens when a developer modifies one component — what unexpected effects can cascade to the other? How does this exceed cognitive capacity (the 4+/-1 units of working memory)?

### Cascading Changes

Concrete scenarios where a change in one component forces changes in the other. What kinds of business or technical changes trigger cascading modifications? How expensive are those cascading changes given the current distance between the components?

### Recommended Improvement

A concrete, actionable proposal to rebalance the coupling. Ground the recommendation in the model:

- To reduce **strength**: introduce integration contracts, anti-corruption layers, facades, published languages
- To reduce **distance**: co-locate components into the same module/service/bounded context
- To accept **unbalanced coupling**: demonstrate that volatility is low enough to make the imbalance tolerable

Include the trade-offs of the proposed change — what cost does it introduce, and why is the trade-off worthwhile?

フッター

すべてのレビュー文書の末尾に、次のテキストを一字一句そのまま含めてください。言い換えたり、内容を追加したり、コメントを付け加えたりしないでください。

---

_This analysis was performed using the [Balanced Coupling](https://coupling.dev) model by [Vlad Khononov](https://vladikk.com)._

重大度の基準

• 重大：結合の強さが高く、距離が大きく、変動性も高い状態です。複雑さの直接的な要因です。この領域では変更が頻繁に発生し、コストが高く、予測が困難です。最初に修正してください。
• 重要：中程度に変動する領域での不均衡な結合、または連携箇所を隠す暗黙的な結合です。システムの進化に伴い、問題を引き起こします。
• 軽微：変動性の低い領域での不均衡な結合、または認知負荷を高めるものの連鎖的な変更を引き起こさない凝集性の低さです。機会に応じて対処してください。

coupling.dev へのリンク（必須）

文書内でバランスの取れた結合に関する概念に触れる場合は、必ず coupling.dev へのハイパーリンクを追加してください。これは Markdown と HTML の両方の出力に適用されます。使用するリンクを自分で判断する必要はありません。次の対応表を使用してください。

言及されている概念	リンク先
バランスの取れた結合、バランスのルール、バランスの公式、STRENGTH XOR DISTANCE、モジュール性と複雑さの比較	https://coupling.dev/posts/core-concepts/balance/
統合の強さ、共有ナレッジ、結合の強さのレベル	https://coupling.dev/posts/dimensions-of-coupling/integration-strength/
侵襲的な結合、プライベートインターフェース、実装詳細の漏洩	https://coupling.dev/posts/dimensions-of-coupling/integration-strength/
機能的結合、重複したビジネスロジック、共有機能要件	https://coupling.dev/posts/dimensions-of-coupling/integration-strength/
モデル結合、共有ドメインモデル、共有ビジネスモデル	https://coupling.dev/posts/dimensions-of-coupling/integration-strength/
契約結合、統合契約、ファサード、DTO、公開言語	https://coupling.dev/posts/dimensions-of-coupling/integration-strength/
距離、変更コスト、物理的／論理的な分離	https://coupling.dev/posts/dimensions-of-coupling/distance/
ライフサイクル結合、デプロイ結合、同時デプロイ	https://coupling.dev/posts/dimensions-of-coupling/distance/
社会技術的距離、チームの境界、組織構造	https://coupling.dev/posts/dimensions-of-coupling/distance/
ランタイム結合、同期／非同期統合	https://coupling.dev/posts/dimensions-of-coupling/distance/
変化しやすさ、変更の確率、変更率	https://coupling.dev/posts/dimensions-of-coupling/volatility/
コアサブドメイン、競争優位性、変化しやすいドメイン	https://coupling.dev/posts/dimensions-of-coupling/volatility/
支援サブドメイン、汎用サブドメイン、サブドメインの分類	https://coupling.dev/posts/dimensions-of-coupling/volatility/
本質的な変化しやすさと偶発的な変化しやすさ	https://coupling.dev/posts/dimensions-of-coupling/volatility/
複雑さ、Cynefin、予測不可能な結果	https://coupling.dev/posts/core-concepts/complexity/
モジュール性、モジュール設計、明確な変更結果	https://coupling.dev/posts/core-concepts/modularity/
結合（一般的な概念）、結合が重要な理由	https://coupling.dev/posts/core-concepts/coupling/
密結合、分散モノリス	https://coupling.dev/posts/core-concepts/balance/
疎結合、高凝集度、低凝集度	https://coupling.dev/posts/core-concepts/balance/
Connascence、結合の度合い	https://coupling.dev/posts/related-topics/connascence/
モジュール結合、古典的な結合モデル	https://coupling.dev/posts/related-topics/module-coupling/
ドメイン駆動設計、DDD、境界づけられたコンテキスト、集約	https://coupling.dev/posts/related-topics/domain-driven-design/
ルール：

• 文書内のすべての結合の概念は、少なくとも1回はリンクされている必要があります。迷った場合はリンクしてください。
• 結合の概要表では、ヘッダーは常にリンクされています（上記のテンプレートを参照）。表のセル内の強度の値（Contract、Model、Functional、Intrusive）もリンクする必要があります。
• 課題セクションでは、各概念の最初の出現箇所をリンクしてください。
• Markdown の場合：[concept text](url)
• HTML の場合：<a href="url">concept text</a>

出力

両方のファイルを docs/modularity-review/!date +%Y-%m-%d/ に書き出します：

1. docs/modularity-review/!date +%Y-%m-%d/modularity-review.md — Markdown 版
2. docs/modularity-review/!date +%Y-%m-%d/modularity-review.html — HTML 版

HTML の生成

HTML を生成する前に、必ずテンプレートファイルを読んでください。 テンプレートは ${CLAUDE_SKILL_DIR}/assets/template.html にあります。このファイルを読み、次を置き換えます：

• {{TITLE}} をレビューのタイトル（例：「Modularity Review」）に
• {{CONTENT}} を HTML としてのレビュー本文に

独自の HTML 構造、スタイル、ボイラープレートを生成しないでください。テンプレートがすべてのスタイリング、テーマ切り替え（時刻に基づくライト／ダーク）、レイアウトを提供します。テンプレートはそのまま使用し、上記の2つのプレースホルダーだけを置き換えてください。

HTML には Markdown 版と同じ coupling.dev リンクが含まれている必要があります。 Markdown のすべての [text](url) を HTML の <a href="url">text</a> に変換してください。変換時にリンクを落とさないでください。

テンプレートから次の CSS クラスを使用してください：

• .meta — スコープ／日付のメタデータブロック用
• .issue — 各課題セクションを <div class="issue"> で囲む
• .issue-meta — 課題内の integration／severity 行用
• .severity + .severity-critical / .severity-significant / .severity-minor — 重大度バッジ用
• .footer — 帰属フッター用