DDD成功应用的基础是创造让业务和系统两种不同认知模型逐步统一的环境,业务架构与技术架构有较深的融合绑定 架构的关键在于合理的封装抽象

领域划分的原则

在一个模块放哪都合适时，参考以下几点

• 第一，依据该模型与边界内其他模型或角色关系的紧密程度。比如当模型变化时，其他模型也需要进行变；该数据是否通畅由当前上下文中的角色在当前活动范围内使用
• 第二，服务边界内的业务能力职责单一，不是完成同一业务能力的模型，不放在同一上下文中。
• 第三，划分资源和服务需要满足正交原则。领域名字代表的自然语言上下文保持相互独立。
• 第四，读写分离原则。例如报表需有单独的报表子域。核心子域的划分更多基于来自业务价值的产生方，而非不产生价值的报表系统。
• 第五，模型在很多业务操作中同时被修改和更新
• 第六，组织中业务部分的划分也是一种参考，一个业务部门的存在往往有起独特业务价值

领域划分建议

• 区分业务能力还是计算能力
• 尽早剥离通用领域
• 时刻促进技术人员与客户、业务人员对话

拆分方法与策略

• 绞杀者模式

指遗留在系统外围，将新功能用新的方式构建为新的服务。随着时间的推移，新的服务逐渐“绞杀”老的遗留系统。对于那些老旧庞大难以更改的遗留系统，推荐使用该模式

• 修缮者模式

就如修房或修路一样，将老旧待修缮的部分进行隔离，用新的方式对其进行单独修复。修复的同时，需保证与其他部分仍协同功能

服务设计原则

• 服务必须有明确边界
• 服务要有清晰的契约设计，即明确的对外能力
• 服务内部保持高度的模块化
• 服务是可被测试的

价值

• 统一业务语言
• 沉淀业务领域知识
• 清晰业务边界
• 提升变化应对能力