mcpField
A
arch-check

arch-check

github.com/codewithmukesh测试与质量7912.9k 次安装12 周前更新
代码仓库

关于 arch-check

arch-check 是用于检查代码库是否遵循既定架构的技能，适合需要验证依赖和端点边界的团队。它支持四种架构基线，并提供带证据和修复建议的违规报告。

主要功能

  1. 01检查四种架构基线
  2. 02审计项目依赖方向
  3. 03检测依赖循环与泄漏
  4. 04检查端点边界
  5. 05报告严重级别、证据和修复建议

适用场景

  1. 01发布前检查架构
  2. 02大型功能完成后复核结构
  3. 03评估继承而来的代码库
  4. 04查找共享模块中的边界违规

MCP 相关

使用 MCP 工具检查项目引用、依赖图、符号引用、端点和结构反模式。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill arch-check

安装后在 Claude Code 中输入/arch-check确认已加载。

详细介绍

/arch-check

内容

验证代码是否仍然符合其所声明的架构。 架构会因一些单独看来都合理的小改动而逐渐腐化——例如 Domain 项目新增了 EF Core 引用、某个模块访问了同级模块的内部实现，或某个端点定义在宿主之外。此工作流通过项目图和依赖关系分析来捕捉这些问题，而非逐个文件阅读。

输出：包含严重级别、文件:行号证据和具体修复方案的违规报告，或通过检查的结果。

适用时机

  • “检查我的架构”“是否存在分层违规”“依赖方向”
  • 发布前，或大型功能合并后
  • 加入一个声称采用了某种架构、但自己并不熟悉的代码库后
  • 多人向共享模块合并代码的团队定期检查
  • 不适用于选择架构——这属于 architecture-advisor 的职责

工作方式

步骤 1：确认已声明的架构

按权威性从高到低依次为：项目的 CLAUDE.md、docs/decisions/ 中的 ADR，或询问用户。绝不默默推断——基准错误会导致报告错误。支持以下四种基准及其规则：

架构检查规则
垂直切片功能之间不得相互引用；共享代码只能通过明确的共享文件夹或项目使用
整洁架构Domain → 无；Application → 仅 Domain；Infrastructure → Application；Api → Application（不得引用 Api → Infrastructure 类型，仅允许接线）
DDD + 整洁架构整洁架构规则 + 只能通过聚合根引用聚合；跨聚合效应使用领域事件
模块化单体模块之间不得有项目引用，*.Contracts 除外；跨模块调用通过集成事件或契约实现

步骤 2：项目级依赖方向（成本最低，能捕捉大多数问题）

get_project_graph()

根据基准中允许的依赖箭头，检查每个项目引用。此处单个错误引用（Domain → Infrastructure）即为 CRITICAL 级别的问题——它会导致所有下游违规都成为可能。

步骤 3：循环依赖

detect_circular_dependencies()

循环依赖在所有基准中都属于违规。报告完整链路。

步骤 4：命名空间级泄漏（抽样检查）

项目引用可能没有问题，但代码仍然可能泄漏。检查风险较高的边界：

get_dependency_graph(symbolName: <a Domain entity>, depth: 2)
   -- Domain types pulling in EF Core, HttpClient, or Infrastructure namespaces?
find_references(symbolName: <a module-internal type>)
   -- referenced from outside its module?
detect_antipatterns()
   -- known structural smells as supporting evidence

根据基准选择抽查对象：整洁架构 → 抽查 3-5 个 Domain 实体和 Application 处理程序；模块化单体 → 抽查每个模块的内部类型；VSA → 抽查两个或三个功能文件夹中的类型。

步骤 5：表示层边界

get_endpoint_map()

端点必须仅位于宿主/Api 层（整洁架构），或其所属模块内（模块化单体、VSA 功能文件夹）。在 Application 或共享项目中定义端点属于边界违规。任何端点缺少标注的身份验证都会作为附带问题报告（如需深入检查，请转到 /security-scan）。

步骤 6：报告

严重级别含义
CRITICAL项目引用方向错误、模块间引用、循环依赖
HIGH命名空间泄漏（Domain 使用 Infrastructure/EF 类型）、端点位于其所属层之外
MEDIUM共享内核逻辑蔓延、通过直接访问成员绕过聚合
INFO端点身份验证未标注、值得关注的反模式命中

每项发现均包含：证据（文件:行号）、违反基准的原因，以及修复方案（移动代码、通过接口反转依赖、引入契约项目、触发集成事件）。主动提出立即修复 CRITICAL 级别的问题。

使用的 MCP 工具
  • get_project_graph — 引用方向审计（核心工具）
  • detect_circular_dependencies — 检测循环依赖
  • get_dependency_graph / find_references — 探查命名空间级泄漏
  • get_endpoint_map — 检查表示层边界和身份验证状况
  • detect_antipatterns — 提供辅助结构证据

示例

User: /arch-check

Claude: Baseline from CLAUDE.md: Clean Architecture (4 projects).

  Project graph (get_project_graph)...
  CRITICAL  Domain → Infrastructure reference (Domain.csproj:14)
            Breaks the dependency rule; makes Domain untestable in isolation.
            Fix: invert — define IEmailSender in Application, implement in
            Infrastructure.
  Cycles (detect_circular_dependencies)... none.
  Leak probes on 4 Domain entities...
  HIGH      Order.cs:8 uses Microsoft.EntityFrameworkCore (Domain must stay
            persistence-ignorant). Fix: move the [Index] config to
            OrderConfiguration in Infrastructure.
  Endpoint map... 23 endpoints, all in Api. 2 unmarked auth (side-finding —
  run /security-scan).

  Verdict: NOT conformant — 1 critical, 1 high. Fix the reference first;
  want me to do it now?

相关

  • architecture-advisor — 选择基线（在此技能发挥作用之前）
  • clean-architecture、vertical-slice、ddd、modular-monolith 模板 — 正在执行的规则
  • /security-scan — 深入检查 auth 方面的发现
  • /health-check — 更全面的评估报告；arch-check 是其中深入检查架构的维度

评论

支持 Markdown