DDD与微服务的不解之缘

DDD与微服务的不解之缘

2003年，Eric出版了那本著名的《Domain-driven Design》，这本书花费了它4年的时间。也就是说，Eric从1999年就开始构思编写DDD了，距今已近二十二年。20多年的时间，在其他领域也许不足为道，但在软件和互联网领域已经足够完成一次次的技术跨越。很难想象，一种软件架构思想历经二十多年不仅没有被淘汰，竟然再次青春焕发！

说到这，DDD得感谢微服务的出现。近些年来，由于互联网行业的快速发展，应用系统逐渐复杂，催生出了微服务思想。微服务提倡对业务单元进行分而治之，各模块自治，从而降低系统的复杂度。而恰巧的是，这竟然和DDD在战略设计部分所提出的限定上下文的思路如出一辙。如果你读过Eric的原著，你甚至可能会有微服务似乎是由DDD衍生而来的错觉。而通过DDD来指导微服务设计，你也会发现几乎没有明显违和感。正因如此，DDD得以借着微服务的流行再次焕发活力，这也是DDD“战略设计”的价值体现，也是当下环境中DDD最重要的价值体现。

1、微服务的粒度应该多大呀？

2、微服务到底应该如何拆分和设计呢？

3、微服务的边界应该在哪里？

DDD核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

都已经有微服务了，为什么还需要DDD呢？

• 沟通难：产品提出一个“小需求”，开发却要做好久，系统到底你懂还是我懂？

• 开发难：代码膨胀。一个类上千行，怎么看？谁能告诉我这段代码有什么用？能不能删掉？

• 测试难：牵一发而动全身，改一个小需求，测试需要组织庞大的测试计划。

• 创新难：系统背负的业务越来越重。已经丧失了对新技术的敏感度。

  log4j2升级！！升不动呀！

  换数据源，换不动呀！

​ 微服务是一个治标不治本的方式。所以我需要在微服务的基础上再多很多很多的设计，这就是DDD为什么时隔那么年再次爆火的原因。

如何解决以上的问题呢？DDD是被认为是目前防止系统膨胀、老化最理想的方式！

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

DDD主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。