Back to Details

spring-architecture-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spring Architecture Review

Spring 架构评审

Review Java/Spring macro structure before local code style. Focus on ownership, boundaries, and dependency direction.
在关注本地代码风格之前，先评审Java/Spring的宏观结构。重点关注归属权、边界和依赖方向。

Workflow

工作流程

  1. Map modules, packages, layers, entrypoints, domain code, infrastructure code, and shared utilities.
  2. Identify intended architecture from README, ADRs, package names, build modules, and existing conventions.
  3. Check changed code against the existing architecture before recommending new patterns.
  4. Prefer minimal moves or dependency fixes over broad rewrites.
  1. 梳理模块、包、分层、入口点、领域代码、基础设施代码和共享工具类。
  2. 从README、ADR、包名、构建模块和现有约定中明确预期架构。
  3. 在推荐新模式之前，先检查变更代码是否符合现有架构。
  4. 优先选择最小化调整或依赖修复，而非大范围重写。

Checks

检查项

  • Package layout communicates ownership: by feature/domain where project already favors it, by layer only when established.
  • Dependencies point inward or downward according to the chosen architecture.
  • Cyclic dependencies between packages, modules, or Maven artifacts are treated as architecture bugs.
  • Domain/application code does not depend on controllers, persistence adapters, web DTOs, or framework-only classes unless the project already accepts that coupling.
  • Controllers delegate orchestration and do not contain business rules.
  • Services/use cases do not leak transport concerns or ORM-specific details across boundaries.
  • Repositories/adapters hide persistence details behind existing project contracts.
  • Shared utilities are cohesive, named by responsibility, and not a dumping ground.
  • Large mixed-purpose packages, god services, and catch-all 
    common
    modules are flagged with concrete split points.
  • Anemic domain models are flagged only when behavior clearly belongs with domain state in this project style.
  • Modules expose narrow APIs and avoid cyclic dependencies.
  • Configuration, bootstrapping, and infrastructure stay outside core business logic.
  • Tests enforce or at least reflect critical module boundaries.
  • 包布局需体现归属权：若项目已倾向按功能/领域划分则遵循此方式，仅在已有约定时才按分层划分。
  • 依赖需按照所选架构向内或向下指向。
  • 包、模块或Maven构件之间的循环依赖视为架构缺陷。
  • 领域/应用代码不得依赖控制器、持久化适配器、Web DTO或仅框架类，除非项目已接受此类耦合。
  • 控制器仅负责委托编排，不得包含业务规则。
  • 服务/用例不得跨边界泄露传输相关问题或ORM特定细节。
  • 仓库/适配器需通过现有项目契约隐藏持久化细节。
  • 共享工具类需内聚，按职责命名，而非杂乱的存放地。
  • 标记大型多用途包、上帝服务和万能
    common
    模块，并给出具体拆分点。
  • 仅当项目风格中行为明显应与领域状态结合时，才标记贫血领域模型。
  • 模块需暴露窄API，避免循环依赖。
  • 配置、启动和基础设施代码需与核心业务逻辑分离。
  • 测试需强化或至少反映关键模块边界。

Output

输出格式

Use concrete paths and dependency evidence.
text
[severity] [file/package]: [boundary issue]
Why it matters: [architecture impact]
Minimal fix: [move, invert dependency, rename package, or introduce existing abstraction]
See EXAMPLES.md for Java/Spring architecture examples.
使用具体路径和依赖证据。
text
[严重程度] [文件/包]: [边界问题]
影响原因: [架构影响]
最小修复方案: [移动代码、反转依赖、重命名包或引入现有抽象]
查看EXAMPLES.md获取Java/Spring架构示例。