When to Use
Working in corporate environments where decisions involve legacy systems, formal processes, compliance, multi-team coordination, or architectural trade-offs at scale.
Quick Reference
| Topic | File |
|---|
| Legacy patterns | INLINECODE0 |
| Compliance rules |
compliance.md |
| Architecture decisions |
architecture.md |
Core Rules
1. Legacy First Mindset
- - Assume existing systems until proven otherwise
- Integration cost > development cost in most decisions
- "Replace vs wrap" analysis before any architecture change
- Document all integration points touched
2. Stakeholder Mapping
| Role | Cares About | Language |
|---|
| Engineering | Technical debt, velocity | Patterns, trade-offs |
| Product |
Features, timeline | User impact, scope |
| Security | Risk, compliance | Threat models, controls |
| Finance | Cost, ROI | TCO, licensing |
| Legal | Liability, data | Contracts, GDPR |
Translate technical decisions into each stakeholder's language.
3. Change Management
- - No breaking changes without migration path
- Feature flags before hard switches
- Rollback plan for every deployment
- Document blast radius of failures
4. Compliance Awareness
- - PCI, SOC2, HIPAA, GDPR implications in every data decision
- Audit trail requirements → logging design
- Data residency affects architecture
- Ask: "Who audits this? What do they need?"
5. Documentation as Deliverable
Enterprise code without docs = technical debt.
- - ADRs (Architecture Decision Records) for major choices
- Runbooks for operations
- API contracts before implementation
- Dependency graphs updated with changes
6. Security by Default
- - Principle of least privilege in all designs
- Secrets in vault, never in code or config files
- Network segmentation assumptions
- Zero trust between services
7. Observability Investment
- - Logging, metrics, tracing from day one
- Correlation IDs across service boundaries
- SLI/SLO definitions before launch
- Alert fatigue is a system design failure
Enterprise Traps
- - Assuming greenfield when there's always legacy → scope explosion
- Optimizing for developer experience over ops burden → 3am pages
- Skipping security review for "internal tools" → breach vector
- Building before buying → reinventing solved problems
- Over-abstracting early → framework nobody understands
- Under-documenting decisions → knowledge silos
技能名称:企业级
适用场景
在企业环境中工作,决策涉及遗留系统、正式流程、合规要求、多团队协调或大规模架构权衡。
快速参考
compliance.md |
| 架构决策 | architecture.md |
核心规则
1. 遗留优先思维
- - 除非有证据表明,否则默认现有系统继续运行
- 在大多数决策中,集成成本 > 开发成本
- 任何架构变更前,先进行替换 vs 封装分析
- 记录所有涉及的集成点
2. 利益相关者映射
| 角色 | 关注点 | 语言 |
|---|
| 工程团队 | 技术债务、开发速度 | 模式、权衡 |
| 产品团队 |
功能、时间线 | 用户影响、范围 |
| 安全团队 | 风险、合规 | 威胁模型、控制措施 |
| 财务团队 | 成本、投资回报率 | 总拥有成本、许可费用 |
| 法务团队 | 责任、数据 | 合同、GDPR |
将技术决策转化为每个利益相关者能理解的语言。
3. 变更管理
- - 没有迁移路径,不得进行破坏性变更
- 硬切换前先使用功能开关
- 每次部署都需制定回滚计划
- 记录故障影响范围
4. 合规意识
- - 每项数据决策都需考虑PCI、SOC2、HIPAA、GDPR的影响
- 审计追踪要求 → 日志设计
- 数据驻留影响架构
- 提问:谁审计这个?他们需要什么?
5. 文档即交付物
企业级代码无文档 = 技术债务。
- - 重大决策需记录架构决策记录(ADR)
- 运维需有操作手册
- 实现前需有API契约
- 依赖图需随变更更新
6. 默认安全
- - 所有设计遵循最小权限原则
- 密钥存放在保险库中,绝不出现在代码或配置文件中
- 默认网络分段
- 服务间零信任
7. 可观测性投入
- - 从第一天起就建立日志、指标和追踪
- 跨服务边界的关联ID
- 上线前定义服务等级指标/服务等级目标(SLI/SLO)
- 告警疲劳是系统设计失败的表现
企业级陷阱
- - 假设是全新项目,却总有遗留系统 → 范围膨胀
- 优化开发者体验而忽视运维负担 → 凌晨三点被叫醒
- 跳过内部工具的安全审查 → 成为攻击入口
- 先自建再购买 → 重复造轮子
- 过早过度抽象 → 无人理解的框架
- 决策文档不足 → 知识孤岛