架构师训练营第十周总结

2004 年 Eric Evans 发表《Domain-Driven Design –Tackling Complexity in the Heart of Software》 （领域驱动设计 ）简称 Evans DDD。但在软件开发领域一直都是雷声大，雨点小，领域驱动设计核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。这几年之所以开始火起来，主要功劳要归功于队友“微服务”，领域驱动设计与微服务架构天生匹配。



领域驱动设计（DDD）是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队利用它可以成功的开发复杂业务软件系统，在系统变大时仍能保持敏捷性

领域驱动设计分为两个阶段：

1. 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；

2. 由领域模型驱动软件设计，用代码来实现该领域模型。

1、领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。

2、领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。

3、领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。 领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。

4、领域驱动设计的思想、原则与模式有助于提高团队成员的架构设计能力。

5、领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。

领域驱动设计是微服务架构的最佳设计方法

领域驱动设计作为一种架构设计方法，微服务作为一种架构风格，两者从本质上都是为追求高响应力目标而从业务视角去分离复杂度的手段。 两者都强调从业务出发，其核心要义强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力（演进式架构） 。

领域驱动设计主要关注：业务领域，划分领域边界；构建通用语言，高效沟通；对业务进行抽象，建立领域模型；维持业务和代码的逻辑一致性。

微服务主要关注：运行时进程间通信，能够容错和故障隔离；去中心化管理数据和去中心化治理；服务可以独立的开发、测试、构建和部署，按业务组织全功能团队；高内聚低耦合，职责单一。