返回 Skill 列表
extension
分类: 开发与工程无需 API Key

architecture-c4-modeling

C4架构建模工作流程用于上下文、容器和组件视图,以明确边界和职责。当团队在重大实施或重构之前需要一个共享的结构模型时使用;不要用它来替代决策记录。

person作者: jakexiaohubgithub

Architecture C4 Modeling

Overview

Use this skill to produce C4 views that remove architectural ambiguity and help teams reason about scope, ownership, and risk.

Scope Boundaries

  • System boundaries are unclear across teams or services.
  • People disagree on where responsibilities belong.
  • A large change requires shared architecture context before coding.

Core Judgments

  • System boundary: what is inside the system and what is external dependency.
  • Container split: what deserves a runtime boundary versus a module boundary.
  • Component granularity: where decomposition clarifies behavior versus adds noise.
  • Trust boundaries and data sensitivity: where stronger controls are required.

Practitioner Heuristics

  • Each relationship in diagrams must answer one operational question: ownership, protocol, failure impact, or data-classification.
  • If two boxes cannot be owned by different teams or deployed/scaled independently, they are usually not separate containers.
  • Component diagrams are useful only for high-change or high-risk containers; do not draw them by default.
  • Keep names consistent with runtime artifacts and code modules to avoid translation loss.

Workflow

  1. Define the audience and the questions each C4 level must answer.
  2. Draw the context view around real external actors and systems.
  3. Draw container boundaries based on runtime and ownership constraints.
  4. Add component views only where behavior is too complex for container-level reasoning.
  5. Annotate critical interactions with trust, latency, and failure assumptions.
  6. Reconcile naming and dependencies with actual repositories and runtime topology.

Common Failure Modes

  • Diagrams mirror org charts instead of runtime behavior.
  • Container boundaries are chosen by technology preference rather than coupling/ownership.
  • Component diagrams become full class diagrams and lose decision value.

Failure Conditions

  • Stop when source system inventory is stale or contradictory.
  • Stop when critical boundaries cannot be represented unambiguously.
  • Escalate when diagram conclusions conflict with approved architectural decisions.