主要观点：

• 采用微服务本为追求独立和敏捷，却因每次部署需协调多团队及测试整个系统，形成分布式单体，虽将复杂性分散至系统，但仍受单体耦合束缚，从技术边界到业务驱动边界的转变才是实现真正敏捷的途径。
• 领域驱动可组合架构（DDCA）提供摆脱这种僵化的方法，通过将服务分解为与业务领域对齐的封装业务能力（PBC），实现真正的服务独立。
• 传统分布式单体架构存在技术边界导致分布式单体的问题，如信用卡奖励处理中单个服务包含多种功能，业务变更时需全量部署。
• DDCA 以业务能力定义服务边界，实现从技术耦合到业务独立的转变，如奖励编排器通过组合独立的 PBC 实现快速新产品引入。
• DDCA 适用于复杂业务域和长期敏捷需求的系统，需具备运营成熟度，采用云原生工具和自动化流程。
• 在 AWS 上，DDCA 可通过映射到 AWS 服务实现，如使用事件驱动通信、弹性编排和事务性输出框等模式。
• 安全方面采用零信任模型在 PBC 边界实施安全，避免共享数据库等反模式。
• DDCA 对组织和业务有影响，如促进团队结构调整、提升产品敏捷性和便于政策审计等。
• 可通过绞杀者图迁移从单体到 PBC，逐步提取高价值的 PBC 并监控迁移效果。

关键信息：

• DDCA 的三个原则：数据所有权、清晰接口、单团队所有权。
• 三种不适合使用 DDCA 的情况：简单 CRUD 系统、主要是技术挑战、团队小且缺乏专业知识。
• AWS 实现 DDCA 的三种模式：事件驱动通信、弹性编排、事务性输出框。
• DDCA 的三个反模式：共享数据库、 orchestrator 含业务逻辑、过度碎片化。
• 绞杀者图迁移从高价值 PBC 开始逐步提取。

重要细节：

• 如在信用卡奖励处理中，传统架构下单个 RewardsService 包含多种功能，业务变更时全量部署；DDCA 下将其拆分为独立的 PBC，如 Merchant Classification、Earning Rate Engine 等，通过 Step Functions 编排，实现快速响应和独立部署。
• 安全方面，每个 PBC 采用零信任模型，通过 IAM 验证调用并授予最小权限，通过 VPC 或账户分离加强边界。
• 迁移过程中从高价值的 Merchant Classification 开始，逐步提取其他 PBC，监控准确性和系统效果。