DDD落地实现的深水区（2）与微服务的整合

支持微服务的DDD架构设计

大家好，我是范钢老师。经过前面一系列的文章，我们对DDD由浅入深出的探讨逐渐进入了深水区。上一期我们探讨了DDD的架构规划与决策，那么DDD的架构设计又应当怎样做呢？如果你是软件项目的架构师，你正在为DDD的软件项目制定架构设计，那么我们一起探讨一下吧。

架构设计实际上是对整个软件项目，站在全局进行的一系列规划与决策。那么第一个要点在于，架构决策的依据是什么呢？你依据什么来决策，到底是选方案A还是方案B呢？毫无疑问，架构决策的依据必须是业务需求，但这样的业务需求不一定是功能性需求，也包括非功能需求。比如，采用DDD开发软件项目，未来的需求是什么呢？未来的软件项目会不断变更，会变得越来越复杂，软件规模会越来越大，使得日后的变更越来越困难，维护成本越来越高。这些是业务痛点，如何解决业务痛点就是我们的业务需求。所以，有一种非常重要的需求分析方法就叫“痛点分析”。

前面已经给大家谈到了，正因为软件规模化与复杂性的难题，我们才需要DDD，DDD就是解决软件复杂性的解决之道。然而，软件复杂性会带来什么样的问题与挑战呢？总结起来有两个：软件规模的复杂性、软件层次的复杂性。先来说说软件规模的复杂性。

软件规模的复杂性就是说，刚开始的时候，客户只提出了比较简单的一些需求，我们对业务的理解也比较浅薄。但随着时间的推移，客户越来越深入地使用这个系统，就会提出越来越多、越来越复杂、越来越细致的需求。我们在不断变更维护去实现这些需求的过程中，就使得系统会做得越来越专业，让客户越来越满意。但与此同时，系统规模就会越来越大，业务逻辑越来越复杂，代码越来越多，不管是业务理解还是需求变更都会越来越困难，这就是“软件规模的复杂性”。

软件规模的复杂性该如何解决呢？那就是通过“分而治之”的思想，将系统拆分成很多个彼此独立的组件。服务端拆分微服务、桌面端拆分动态链接库DLL、嵌入式拆分内核对象KO，都是这种思想的体现，关键是如何拆分。我们希望通过拆分，每次变更都能尽量落地某个组件上去变更，譬如只变更某个微服务，而与其它微服务无关。如果可以这样，不仅变更的范围缩小了，业务也变得易于理解，升级维护也会变得容易。那么，怎样才能做到这一点呢？通过DDD