领域驱动设计-DDD学习笔记

     目前软件研发最火的架构是基于云原生、微服务的架构。微服务设计过程中往往会面临边界如何划定的问题，微服务到底怎么拆分和设计才算合理，拆多小才叫微服务？微服务的拆分有没有可推荐的原则和方法论？目前很多大型互联网企业已经将 DDD 设计方法作为微服务的主流设计方法，近期很荣幸有机会在《极客时间》学习欧创新老师的《DDD实战课》，通过深入 DDD 的核心知识体系，学习如何基于DDD的设计思想和方法设计落地边界清晰、可持续演进的微服务架构。

   一、DDD是什么？

     2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。 但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。

二、DDD核心内容有哪些？

      DDD 的知识体系包含领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等。

     在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子