# 1. Branch by Abstraction 模式中在共享主干上抽象后替换实现（无分支） A 它通过创建长期 feature branch 来并行开发，最后一次性合并 B 它与源码分支完全等价，只是名字不同 C 它只在发布当天执行，不涉及日常演进 D 它用抽象层作为分支替代，在共享主干上让新旧实现并存并逐步迁移，始终可集成可回滚 ✓ 正确答案
# 2. Modular Monolith（模块化单体）作为微服务化的中间形态 A 它内部按清晰边界划分模块但整体统一部署，可先理清边界再按需拆分，是微服务化的中间形态 ✓ 正确答案 B 它是多个独立部署的微服务 C 它等于传统大泥球单体，无任何模块边界 D 它无法复用事务一致性，只能靠分布式事务
# 3. 并行架构演进的节奏管理中如何用演进看板（候选/计划/进行/验证）与适应度函数门禁管理多个同时进行的架构演进，避免相互干扰？ A 并行演进越多越好，无需节奏与控制 B 看板只用于展示，不参与治理 C 演进只能串行，一次只能做一个 D 用演进看板管理阶段并限制在制品，用适应度函数门禁作为完成标准，控制冲突 ✓ 正确答案
# 4. 适应度函数的分类中原子与整体、动态与静态、有损与无损如何选择，演进中如何随约束调整？ A 有损函数永远比无损函数更好，应全部使用 B 所有函数都必须是无损的，否则无法信任 C 适应度函数一旦定好就永不改变 D 无损函数精确但成本高，有损函数成本低但可能漏报，需按精度需求权衡并随演进动态调整 ✓ 正确答案
# 5. Neal Ford 的"Building Evolutionary Architectures"中的引导式（Guided）vs 演进式（Evolutionary）变更 A 两者互斥，只能选择其一 B 引导式不需要任何度量或门禁 C 演进式完全不需要目标，漫无边际 D 引导式是目标明确的大变革，演进式是小步持续增量，二者互补并依赖适应度函数作护栏 ✓ 正确答案
# 6. 微服务拆分（decomposition）的四策略中 By Business Capability、By Subdomain、By Strangler Fig、By Self-Contained Service A 四种策略互斥，只能严格选一种 B 应按技术层次（controller/service/repository）拆分 C 它们分别按业务能力、领域子域、渐进替换、自包含调用链拆分，可混合使用以高内聚低耦合为边界标准 ✓ 正确答案 D 拆分只与数据库无关，无需考虑数据所有权
# 7. 演进式架构（Evolutionary Architecture）的"适应度函数"（fitness function）定义中性能、安全、可修改性的客观度量 A 架构属性只能靠架构师主观评审来度量 B 适应度函数对性能、安全、可修改性等属性进行客观、可量化、可自动化的度量，使约束可验证可门禁 ✓ 正确答案 C 适应度函数只能度量性能，无法度量安全与可修改性 D 度量无需自动化，手工执行即可
# 8. 绞杀者模式中的 Facade / Anti-Corruption Layer 的逐步迁移 A Facade 负责翻译数据模型，防腐层负责路由切换 B Facade 提供统一入口路由新旧实现，防腐层隔离并翻译新旧系统的模型差异，实现平滑渐进迁移 ✓ 正确答案 C 绞杀者模式是一次性整体替换，无需 Facade D 防腐层会直接暴露旧系统内部结构给新系统
# 9. 分布式单体（Distributed Monolith）的反模式诊断 A 它是真正独立的微服务，拆分完全正确 B 它比传统单体更简单，无需关注耦合 C 它名义上是微服务但服务间强耦合（共享数据库、同步调用链长、分布式事务），既无独立演进又背负分布式成本 ✓ 正确答案 D 分布式单体没有任何共享约束，服务完全自治
# 10. 架构演进的驱动力中规模、团队与业务变化？ A 架构演进应紧跟技术潮流，不必看业务需求 B 规模、团队、业务三类变化是架构演进的主要驱动力，演进应与之匹配而非为技术而演进 ✓ 正确答案 C 只有规模增长才值得演进，团队与业务无关 D 架构一旦确定就永不演进
# 11. 架构演进中数据层的分阶段迁移中双写、对账、切流、清理四个阶段各自的验收标准与回滚条件如何定义？ A 迁移无需阶段划分，一次性切换即可 B 双写、对账、切流、清理各阶段都需明确的量化验收标准与可执行的回滚条件，保证迁移可逆 ✓ 正确答案 C 清理阶段删除数据后无需担心回滚 D 对账阶段只需人工抽查，无需量化一致率
# 12. 微服务拆分前的耦合预检中共享表、隐式远程调用与事件依赖如何识别，并决定拆分顺序？ A 拆分前无需预检，直接按模块拆即可 B 共享表不影响拆分，可随意拆分 C 通过分析共享表、隐式远程调用与事件依赖识别耦合，先拆边界清晰低耦合的模块，高耦合后拆 ✓ 正确答案 D 拆分顺序与耦合无关，任意即可
# 13. 微服务化的"过早拆分"（premature decomposition）的代价 A 过早拆分会带来分布式复杂度、边界错误、数据一致性等成本，应在边界与规模明确后再拆 ✓ 正确答案 B 拆分越早越好，收益立竿见影 C 过早拆分没有任何代价 D 微服务拆分与团队规模、业务边界无关
# 14. 微服务的"过早合并"（premature consolidation）的反向代价 A 合并总是越早越好，可减少运维成本 B 合并任何服务都无需考虑边界与团队需求 C 过早合并与过早拆分同样是最优策略 D 过早合并会失去独立部署/扩展与故障隔离能力，应只在独立演进收益低、边界高内聚时合并 ✓ 正确答案
# 15. 演进模式中增量重构、Strangler 与绞杀者？ A 增量重构小步改善内部结构，绞杀者渐进构建新系统替换旧功能，按系统可维护程度与替换需求选择 ✓ 正确答案 B 增量重构适合整体替换遗留系统，绞杀者适合小步改善 C 两种模式完全等价，无区别 D 绞杀者是一次性整体替换，无渐进性
# 16. 架构演进的风险中兼容与回滚？ A 通过向后兼容、版本化、契约测试控制兼容风险，通过设计回滚点、灰度开关、备份保证演进可逆 ✓ 正确答案 B 演进无需考虑兼容，直接破坏即可 C 回滚只能靠人工重写代码，无法提前设计 D 兼容只需保证接口，数据与契约无关
# 17. 架构决策的记录与复盘？ A 架构决策只需口头决定，无需记录 B 用 ADR 记录决策背景、取舍与后果，并定期复盘验证效果，形成决策-执行-验证-修订的闭环 ✓ 正确答案 C ADR 只在项目结束后一次性补写 D 复盘与决策记录无关，是浪费时间
# 18. 演进中的依赖治理中模块边界？ A 模块边界只需在初始设计时划定，之后无需维护 B 演进中越界依赖不会影响边界，无需治理 C 用依赖规则工具把允许/禁止依赖固化为门禁，并渐进收敛存量违规、持续守护新增依赖 ✓ 正确答案 D 依赖治理是一次性检查，与后续演进无关
# 19. 架构演进的成本决策中拆分与维持现状的长期成本如何估算对比，避免凭感觉演进？ A 用一次性/长期成本、收益、技术债等多维度量化对比拆分与维持现状，以长期价值（如 ROI）为依据 ✓ 正确答案 B 架构演进应凭感觉与潮流决定，无需量化 C 维持现状永远不需要算成本 D 拆分成本无法估算，只能拍脑袋
