architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Architect — Phase d'architecture avant TDD

架构师——TDD前的架构阶段

Skill inspiré de obra/superpowers. Objectif : produire une spec d'architecture avant d'écrire le moindre test ou ligne de code.

Règle d'or : si tu ne peux pas dessiner le diagramme, tu ne peux pas coder la feature.

本Skill灵感来自obra/superpowers。目标： 在编写任何测试或代码行之前生成架构规范。

黄金法则： 如果你无法画出流程图，就无法编码该功能。

Quand utiliser

何时使用

Situation	Architect phase ?
Bug 1 fichier	❌ Non (go direct TDD)
Nouvelle feature < 3 fichiers	⚠️ Court (10 min)
Nouvelle feature > 3 fichiers	✅ Obligatoire
Nouveau module/bounded context	✅ Obligatoire
Migration technique	✅ Obligatoire
Intégration externe (API, MQ, DB)	✅ Obligatoire

场景	是否需要架构阶段？
单文件Bug修复	❌ 不需要（直接进行TDD）
涉及少于3个文件的新功能	⚠️ 简短进行（10分钟）
涉及多于3个文件的新功能	✅ 必须进行
新模块/限界上下文（bounded context）	✅ 必须进行
技术迁移	✅ 必须进行
外部集成（API、MQ、DB）	✅ 必须进行

Processus en 5 étapes

5步流程

1. Identifier les boundaries

1. 识别边界

Quelles frontières la feature touche-t-elle ?

Domain boundaries — quels bounded contexts impliqués ?
Layer boundaries — Presentation / Application / Domain / Infrastructure ?
Process boundaries — sync HTTP / async queue / event-driven ?
Data boundaries — quelles bases de données, quelles tables ?
Ownership boundaries — quelle équipe owne quel morceau ?

Output : liste des frontières traversées.

该功能涉及哪些边界？

领域边界 —— 涉及哪些限界上下文（bounded context）？
分层边界 —— 表现层/应用层/领域层/基础设施层？
流程边界 —— 同步HTTP/异步队列/事件驱动？
数据边界 —— 涉及哪些数据库、哪些表？
所有权边界 —— 哪个团队负责哪部分？

输出： 跨越的边界列表。

2. Définir les contrats

2. 定义契约

Pour chaque frontière traversée, définir le contrat :

Inputs : format, types, invariants, nullabilité
Outputs : format, codes d'erreur, latence cible
Side effects : écritures DB, events émis, appels externes
Idempotence : le contrat est-il idempotent ?
Transactions : atomique ? eventually consistent ?

Output : signatures de fonctions/endpoints + DTO.

对于每个跨越的边界，定义契约：

输入：格式、类型、不变量、可空性
输出：格式、错误码、目标延迟
副作用：数据库写入、事件发布、外部调用
幂等性：契约是否具备幂等性？
事务：原子性？最终一致性？

输出： 函数/端点签名 + DTO。

3. Dessiner les dépendances

3. 绘制依赖关系

Qui dépend de quoi ? Dans quel sens ?

[HTTP Controller] ──▶ [Use Case] ──▶ [Domain Service]
                                          │
                                          ▼
                                     [Repository] (interface)
                                          │
                                          ▼
                        [Postgres Adapter] ─implements─▶

Vérifier :

Pas de cycle (A → B → A)
DIP respecté (domain ne dépend pas de l'infra)
Pas plus de 3 niveaux d'appel entre entrée et côté métier

Output : diagramme (Mermaid, ASCII, ou texte structuré).

谁依赖于谁？依赖方向如何？

[HTTP Controller] ──▶ [Use Case] ──▶ [Domain Service]
                                          │
                                          ▼
                                     [Repository] (interface)
                                          │
                                          ▼
                        [Postgres Adapter] ─implements─▶

检查项：

无循环依赖（A → B → A）
遵循依赖倒置原则（DIP）——领域层不依赖于基础设施层
从入口到业务逻辑的调用层级不超过3层

输出： 流程图（Mermaid、ASCII或结构化文本）。

4. Lister les trade-offs

4. 列出权衡方案

Pour chaque décision non évidente, documenter pourquoi ce choix :

Décision	Alternative envisagée	Pourquoi ce choix
Async via queue	Sync HTTP	Latence >500ms, pas critique immédiat
CQRS	CRUD simple	Ratio 20:1 lecture/écriture
Event sourcing	Store état	Besoin audit légal

Output : ADR léger (3-5 bullets) — voir

.claude/rules/10-documentation.md

pour ADR formel si décision majeure.

对于每个非显而易见的决策，记录为何选择该方案：

决策	考虑的替代方案	选择理由
通过队列实现异步	同步HTTP	延迟>500ms，非紧急关键需求
CQRS	简单CRUD	读写比为20:1
事件溯源（Event sourcing）	状态存储	符合法定审计需求

输出： 轻量ADR（3-5条要点）——若为重大决策，参考

.claude/rules/10-documentation.md

中的正式ADR规范。

5. Définir les tests d'architecture

5. 定义架构测试

Avant TDD sur le comportement, définir les tests d'architecture :

Tests de dépendances (ArchUnit, Dephpend, deptrac)
Tests de contrats (OpenAPI validation, contract tests)
Tests de performance cibles (latence p99, throughput)
Tests d'isolation multitenant si applicable

Output : liste de tests d'architecture à écrire en Phase TDD.

在针对行为进行TDD之前，定义架构测试：

依赖测试（ArchUnit、Dephpend、deptrac）
契约测试（OpenAPI验证、契约测试）
目标性能测试（p99延迟、吞吐量）
多租户隔离测试（如适用）

输出： 需在TDD阶段编写的架构测试列表。

Livrables

交付物

À la fin de la phase Architect, produire :

Diagramme dépendances (1 page max)
Contrats des frontières (signatures + DTO)
ADR court trade-offs principaux
Liste de tests d'architecture
Découpage en tâches atomiques (voir skill
```
atomic-tasks
```
)

Ce n'est qu'après qu'on rentre dans le TDD (Red/Green/Refactor).

架构阶段结束时，需生成：

依赖关系图（最多1页）
边界契约（签名 + DTO）
简短ADR（主要权衡方案）
架构测试列表
原子任务拆分（参考Skill
```
atomic-tasks
```
）

只有完成上述步骤后，才能进入TDD阶段（红/绿/重构）。

Anti-patterns

反模式

Anti-pattern	Solution
Coder directement sans diagramme	Dessiner AVANT, même 5 min suffisent
Architect phase > 2h sur feature simple	YAGNI — couper court
Contrats flous ("objet User")	Types stricts, tous les champs
Ignorer les trade-offs	ADR court obligatoire
Architecture en vase clos	Review par un pair ou subagent `@tech-lead`

反模式	解决方案
直接编码而不绘制流程图	先绘制流程图，即使仅需5分钟
简单功能的架构阶段耗时超过2小时	遵循YAGNI原则——缩短流程
契约模糊（如“User对象”）	使用严格类型，明确所有字段
忽略权衡方案	必须编写简短ADR
闭门造车式架构设计	由同事或子代理 `@tech-lead` 进行评审

Intégration Claude Craft

Claude Craft集成

/workflow:design
— utilise ce skill par défaut
Agent
@tech-lead
— peut produire l'output Architect
ADR formel : voir
```
/common:architecture-decision
```
Rule 04 SOLID + Rule 17 CQRS + Rule 14 Multitenant — consulter selon contexte

/workflow:design
—— 默认使用本Skill
代理
@tech-lead
—— 可生成架构阶段输出
正式ADR：参考
```
/common:architecture-decision
```
规则04 SOLID + 规则17 CQRS + 规则14 Multitenant —— 根据上下文参考

Ressources

资源

obra/superpowers
Rule
```
.claude/rules/04-solid-principles.md
```
Rule
```
.claude/rules/10-documentation.md
```
(ADR)
Skill
```
atomic-tasks
```

Date de dernière mise à jour : 2026-04-15 Version : 1.0.0

obra/superpowers
规则
```
.claude/rules/04-solid-principles.md
```
规则
```
.claude/rules/10-documentation.md
```
（ADR）
Skill
```
atomic-tasks
```

最后更新日期： 2026-04-15 版本： 1.0.0