From team-standards
Enforces DDD-lite layering, feature modules, and one-way dependencies in Java Spring Boot, React, Vue, Flutter apps before writing or reviewing business code.
npx claudepluginhub exception-coder/team-standards --plugin team-standardsThis skill uses the workspace's default tool permissions.
该项目采用 DDD-lite + Feature 模块化架构,目标是:代码结构清晰、易于维护、低耦合、高内聚、可复用、可扩展、适合 AI 协作开发。
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Executes ctx7 CLI to fetch up-to-date library documentation, manage AI coding skills (install/search/generate/remove/suggest), and configure Context7 MCP. Useful for current API refs, skill handling, or agent setup.
Share bugs, ideas, or general feedback.
该项目采用 DDD-lite + Feature 模块化架构,目标是:代码结构清晰、易于维护、低耦合、高内聚、可复用、可扩展、适合 AI 协作开发。
任何业务代码,必须先判断属于哪一层,再实现;不允许直接写在 Controller / UI / Page 中。
清晰结构不是“代码写完后再优化”的附加项,而是第一行代码前的门禁。AI 不得为了快速完成而新增难读、难测、难替换、职责混杂的实现。
在以下场景必须主动调用本 Skill:
| 场景 | 动作 |
|---|---|
| 准备编写 Java / React / Vue / Flutter 业务代码 | 先判断代码所属层级与 feature 模块 |
| 根据设计文档或 coding.md 开始实现 | 在第一行源码改动前完成分层检查 |
| 新增接口、页面、UseCase、Service、Repository、DAO、HTTP Client | 明确职责边界和调用链 |
| 重构现有业务逻辑 | 先识别现有逻辑应沉到 Application / Domain / Infrastructure 的哪一层 |
| 代码审查发现跨层调用、巨型 Service、重复业务逻辑 | 用本规范判定违规类型 |
| 代码实现可能继续沿用低质量旧结构 | 先判断是否会增加耦合、职责混杂或维护成本 |
UI / Controller / Page
↓
Application(UseCase / Service)
↓
Domain(业务规则)
↓
Repository(数据抽象)
↓
Infrastructure(DB / HTTP / MQ / Storage)
所有业务代码必须按 feature 组织,而不是按技术层全局平铺。
features/
{feature_name}/
presentation/ # UI / Controller / Page
application/ # UseCase / Application Service / Composable Service
domain/ # Entity / Value Object / Rule / Policy / State Machine
repository/ # Repository 接口定义
infrastructure/ # Repository 实现、DB、HTTP、MQ、Storage
api/ # 前端 HTTP 请求封装
dao/ # Flutter 本地数据访问
components/ # 前端纯展示组件
hooks/ # React Hook / Vue Composable / 状态编排
types/ # DTO / ViewModel / 类型定义
| 项目复杂度 | 允许简化 | 禁止事项 |
|---|---|---|
| 简单项目 | 可省略独立 Domain 目录,把简单规则放在 Application 内部私有方法 | 不能让 UI / Controller 直接访问 DB / HTTP |
| 中型项目 | 使用完整 DDD-lite 分层 | 不能把所有逻辑塞进单个 Service |
| 复杂系统 | DDD-lite + 状态机 + 领域事件 + 原子能力沉淀 | 不能跨 feature 随意 import 内部实现 |
职责:
禁止:
职责:
要求:
职责:
禁止:
职责:
示例:
OrderRepository
findById()
save()
findRefundableItems()
禁止:
职责:
禁止:
所有通用业务能力必须抽象为可复用的原子能力,避免多个 UseCase 重复实现同一段业务逻辑。
命中任一条件,应沉淀为原子能力:
| 条件 | 示例 |
|---|---|
| 被两个及以上 UseCase 复用 | 退款金额计算、订单可退校验 |
| 代表稳定业务规则 | 状态流转校验、会员价计算 |
| 需要独立测试 | 手续费分摊、优惠抵扣拆分 |
| 未来可能被接口、定时任务、消息消费共同调用 | 退款终态登记、库存释放 |
RefundService
validateRefundable()
calculateRefundAmount()
createRefundTransaction()
callRefundChannel()
registerRefundFinalState()
禁止在多个 UseCase 中重复写同一份退款、支付、库存、订单状态流转逻辑。
所有业务代码在实现前必须满足以下结构质量要求。若无法满足,必须先调整设计或拆分实现,不能带着明显结构债继续编码。
默认原则:扩展现有能力时,新代码放到新结构(新 service / 新子门面 / 新原子能力)并暴露公开方法,旧代码只调用一行——不要在旧文件里就地堆叠新增逻辑。
为什么这是默认默认行为而不是可选优化:
| 后果 | 在旧代码就地堆叠 | 新结构暴露 + 旧代码引用 |
|---|---|---|
| 旧文件污染面积 | 持续扩大(每次扩展 +N 行) | 每次只 +1 行调用 |
| 新代码是否符合目标态规范 | 跟旧代码同污染(裸 SQL / 内联决策门 / 巨型方法) | 一开始就符合(DAO 唯一容器 / 私有方法粒度 / 强类型) |
| 后续重构成本 | 新增的 N 行也要再迁一次 | 已经在目标态,无需再迁 |
| 可单元测试粒度 | 与旧巨型方法绑定,只能整体测 | 新方法独立可测 |
| 调用方迁移路径 | 旧代码删除前不能切换 | 新结构稳定后调用方可立刻切换 |
触发场景(满足任一就必须按本原则落点):
正确决策流程(编码前必须走完):
import + 调用一行反模式(即使旧代码本来就乱也不允许):在 1500 行的历史方法中再加 95 行新逻辑、跟旧风格混在一起、SQL 内联、决策门 inline、字段名靠字符串 key——只因为"旧代码已经这样了我跟着抄"。这是把新代码的目标态成本一并计入未来重构债。
| 禁止行为 | 正确处理 |
|---|---|
| 为了快,直接复制一个相似文件再改几行 | 先识别可复用能力,必要时抽象公共能力或拆分职责 |
| 一个方法同时处理参数适配、业务判断、SQL、HTTP、日志流水 | 按 Presentation / Application / Domain / Infrastructure 拆分 |
| 为了少建文件,把多个业务场景塞进一个 Service | 按 UseCase 或原子能力拆分,保持单一职责 |
| 上层直接依赖 DAO / HTTP Client / 其它 feature 内部类 | 通过 Repository、Application Service 或能力端口隔离 |
| 继续沿用低质量旧结构,只因为项目里已有类似写法 | 先评估现有代码质量;差结构只能提取业务事实,不能扩散 |
| 在已有的巨型方法 / 旧骨架文件里就地追加新逻辑(新增 N 行内联在旧代码段里) | 新逻辑放到新 service / 新子门面 / 新原子能力暴露 public 方法,旧文件只 +1 行调用,详见「新代码落点决策」节 |
适用于 React / Vue。
标准调用链:
Page
↓
Hook / Composable
↓
Service
↓
API
强制规则:
api/ 层。标准调用链:
Widget
↓
ViewModel / Provider / StateNotifier
↓
Application Service / UseCase
↓
Repository
↓
Infrastructure / DAO / HTTP
强制规则:
适用于 Spring Boot / Spring Cloud。
标准调用链:
Controller
↓
Application Service / UseCase
↓
Domain Service / Policy / Entity
↓
Repository Interface
↓
Infrastructure Mapper / Client / MQ Adapter
强制规则:
| 类型 | 命名示例 |
|---|---|
| UseCase | ConfirmRefundUseCase |
| Application Service | RefundApplicationService |
| Domain Service / 原子能力 | RefundService |
| Repository 接口 | OrderRepository |
| Repository 实现 | OrderRepositoryImpl |
| Controller | RefundController |
| React Hook | useRefund |
| Vue Composable | useRefund |
| Flutter ViewModel | RefundViewModel |
写第一行业务代码前,必须逐项确认:
当本 Skill 参与编码时,AI 在动手前必须先给出简短分层判断:
分层判断:
- Feature:{feature_name}
- Presentation:{是否涉及,文件/类}
- Application:{是否涉及,文件/类}
- Domain:{是否涉及,文件/类}
- Repository:{是否涉及,文件/类}
- Infrastructure:{是否涉及,文件/类}
- 原子能力复用/新增:{说明}
- 结构质量:{清晰性 / 可维护性 / 低耦合 / 高内聚判断}
如果无法判断层级,必须先读取项目结构或设计文档;仍无法判断时,向用户确认,不得直接把逻辑写进 UI / Controller。
| 想法 | 正确处理 |
|---|---|
| "这个逻辑很短,直接写 Controller 里" | 先判断是否是业务规则;是则下沉 Application / Domain |
| "页面直接调 API 更快" | API 封装到 api 层,页面调用 hook / service |
| "Repository 实现里顺便编排业务流程" | 编排放 Application,Infrastructure 只做技术实现 |
| "多个 UseCase 复制一段计算逻辑" | 抽成原子能力并补测试 |
| "Domain 里注入 HTTP Client / Mapper" | Domain 保持纯业务,技术依赖放 Infrastructure |
| "一个 Service 什么都管" | 按 UseCase / 原子能力拆分,职责单一 |
| "先能跑,结构以后再说" | 结构质量是编码前门禁,先拆职责和依赖边界再写 |
| "复制旧实现最快" | 先判断旧实现是否值得参考;低质量旧结构不能扩散 |