specsfy-specialist-software-architecture

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Arquitetura de software

软件架构

Quando usar

适用场景

Acionar para decisão com custo alto de reverter: introduzir um serviço, uma fila, um cache distribuído, mudar o boundary entre módulos ou a direção de uma dependência estrutural.
Acionar também quando um atributo de qualidade (latência, disponibilidade, consistência, capacidade) precisar virar critério explícito de decisão.
Não acionar para renomear, mover arquivo ou refatorar localmente sem impacto de boundary — isso é manutenção, não decisão arquitetural.
Rodar
```
$specsfy-specialist-domain-modeling
```
primeiro quando o boundary em disputa for de um conceito de domínio ainda não modelado — a arquitetura decide onde colocar um boundary já definido pelo domínio, não o inventa.

适用于高回滚成本的决策：引入服务、消息队列、分布式缓存，变更模块间的boundary（边界）或结构性依赖方向。
当质量属性（延迟、可用性、一致性、容量）需要成为明确的决策标准时，也可启用。
不适用于重命名、移动文件或无边界影响的本地重构——这些属于维护操作，而非架构决策。
当存在争议的boundary（边界）属于尚未建模的领域概念时，请先运行
```
$specsfy-specialist-domain-modeling
```
——架构负责确定领域已定义的边界位置，而非凭空创造边界。

Fluxo

流程

Definir finalidade do sistema, restrições reais (orçamento, prazo, time disponível) e cenários de atributo de qualidade mensuráveis (não adjetivos como "escalável").
Mapear o estado observado: owners de dados, dependências existentes entre módulos/serviços, fluxos de runtime críticos e onde a dor atual está.
Identificar as forças em conflito, as decisões que seriam caras de reverter depois e os riscos de cada caminho.
Comparar opções pelos mesmos critérios (os cenários do passo 1) e pelo custo operacional real de cada uma — rede, consistência distribuída, observabilidade adicional, times a coordenar.
Escolher a menor estrutura que satisfaz os cenários definidos — a opção mais simples que atende o atributo de qualidade vence por padrão.
Definir plano de transição: compatibilidade durante a migração, observabilidade para detectar regressão e um caminho de rollback real.
Registrar a decisão (ADR) e verificar os boundaries propostos por teste de dependência automatizado ou análise estática, quando possível.

定义系统目标、实际约束条件（预算、期限、可用团队）以及可衡量的质量属性场景（避免使用“可扩展”这类形容词）。
梳理当前状态：数据负责人、模块/服务间的现有依赖、关键运行时流程以及当前痛点所在。
识别冲突因素、后续回滚成本高的决策，以及每种方案的风险。
基于相同标准（步骤1中的场景）和各方案的实际运营成本（网络、分布式一致性、额外可观测性、团队协作成本）对比选项。
选择能满足既定场景的最简架构——默认选择符合质量属性要求的最简单方案。
制定迁移计划：迁移期间的兼容性、用于检测回归的可观测性方案，以及切实可行的回退路径。
记录决策（ADR），并尽可能通过自动化依赖测试或静态分析验证提议的boundaries（边界）。

Padrões

架构模式

Dar a cada módulo responsabilidade, dados e interface claros — um módulo sem contrato explícito vira acoplamento implícito para quem o consome.
Direcionar dependências das políticas voláteis para as estáveis (regra de dependência): módulo de negócio não deve depender de detalhe de framework/infra; o inverso é o padrão saudável.
Evitar introduzir serviço, fila, cache ou camada de abstração sem um cenário consumidor real e mensurável que a justifique — abstração especulativa cria custo permanente por benefício hipotético.
Separar explicitamente a arquitetura implementada (o que existe hoje) da arquitetura desejada (para onde está migrando) — tratá-las como a mesma coisa esconde dívida e trabalho pendente.
Expressar todo atributo de qualidade como cenário mensurável: estímulo, ambiente, resposta esperada, medida (ex.: "sob 200 req/s, p99 < 300ms"), nunca como adjetivo solto.
Manter decisões facilmente substituíveis como locais e reversíveis, e tornar explícitas (ADR) apenas as decisões realmente caras de mudar depois.
Evoluir arquitetura por seams verificáveis e incrementais (strangler fig, expand/contract) em vez de reescrita completa — reescrita total raramente entrega no prazo e perde conhecimento acumulado no sistema atual.

为每个模块明确职责、数据和接口——无显式契约的模块会给使用者带来隐式耦合。
遵循依赖规则：将依赖从易变的策略层指向稳定层——业务模块不应依赖框架/基础设施细节，反之才是健康的模式。
若无真实可衡量的用户场景支撑，请勿引入服务、队列、缓存或抽象层——投机性抽象会产生永久成本，却仅带来假设性收益。
明确区分已实现的架构（当前状态）与目标架构（迁移方向）——将二者混为一谈会掩盖技术债务和待完成工作。
将所有质量属性转化为可衡量的场景：包含触发条件、环境、预期响应、衡量标准（例如：“在200次请求/秒的负载下，p99延迟<300ms”），切勿使用孤立的形容词。
保持易替换的决策本地化且可回退，仅将后续变更成本极高的决策通过ADR明确记录。
通过可验证的增量式接缝（strangler fig、expand/contract模式）演进架构，而非完全重写——完全重写往往无法按时交付，还会丢失现有系统积累的知识。

Antipadrões

反模式

Adotar microsserviços porque "é o padrão da indústria" sem um cenário de escala, time ou deployment independente que o justifique — o custo de consistência distribuída e operação multiplicada é real e imediato; o benefício é hipotético até que o cenário apareça.
Big ball of mud: módulos sem fronteira nem direção de dependência definida, onde qualquer parte pode chamar qualquer outra diretamente.
Big design up front sem cenário de qualidade mensurável — arquitetura "para o futuro" sem estímulo concreto que a justifique tende a resolver o problema errado e travar decisões reversíveis cedo demais.
Adicionar uma camada de indireção genérica "para flexibilidade futura" quando existe apenas um consumidor real hoje — paga o custo de complexidade antes de haver qualquer evidência de que a flexibilidade será usada.

只因“行业流行”就采用微服务，却无规模、团队独立部署等可支撑的场景——分布式一致性和运维成本的增加是真实且即时的，收益却要等到场景出现后才能体现。
大泥球（Big ball of mud）：模块无明确边界和依赖方向，任意部分可直接调用其他部分。
无衡量质量场景的预先过度设计（Big design up front）——“为未来”设计的架构若无具体触发条件支撑，往往会解决错误的问题，过早锁定可回退的决策。
当当前仅存在一个真实使用者时，为“未来灵活性”添加通用间接层——在无证据表明灵活性会被使用的情况下，提前承担复杂度成本。

Validação

验证

Caminhos críticos, modos de falha, requisitos de consistência e capacidade foram avaliados contra os cenários definidos, não só o caminho feliz.
Existem testes de arquitetura ou de dependência (quando a linguagem/ ferramenta permitir) que travam a direção de dependência decidida.
Há ensaio da migração: compatibilidade durante a transição, plano de rollback testado, não apenas descrito.
Impactos em segurança, dados e operação foram revisados como parte da decisão, não como reflexão posterior.
Não declarar uma arquitetura "escalável" ou "resiliente" sem o cenário mensurável e a evidência que o comprova — linguagem absoluta sem prova é proibida.

已针对既定场景评估关键路径、故障模式、一致性要求和容量，而非仅考虑正常流程。
存在架构或依赖测试（若语言/工具支持）以锁定已确定的依赖方向。
已进行迁移演练：验证迁移期间的兼容性、测试回退计划，而非仅停留在文档层面。
决策过程中已评估安全、数据和运营影响，而非事后反思。
不得在无可衡量场景和证据支撑的情况下，宣称架构“可扩展”或“具韧性”——禁止使用无依据的绝对表述。

specsfy-specialist-software-architecture

Original

Translation

Arquitetura de software

软件架构

Quando usar

适用场景

Fluxo

流程

Padrões

架构模式

Antipadrões

反模式

Validação

验证

Skills relacionadas

相关技能