DDD为什么能火起来？和微服务有啥关系？
2023-05-24 16:59:17
这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯提出，但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意， 也就是微服务盛行之后， DDD再次回到人们视野中间，为什么呢 ？
我们先看一下三种技术架构的演进以及主要区别：
【 第一阶段:单机架构 】
面向过程的设计方法、包括客户端UI和数据库两层。
特征是整个开发围绕着数据库进行设计和开发。
采用面向对象的设计方法，业务逻辑分业务层、逻辑层、数据访问层。
这种架构很容易某一层或者几层变得臃肿，扩展性较差， 另外摩尔定律失效， 单台机器性能有限。
在第二阶段-集中式架构中，系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，就涉及到交流信息丢失的问题，另外项目从分析到开发经历的流程很长，很容易最终开发设计与需求实现的不一样。
微服务主要就是解决第二阶段的这些痛点，实现应用之间的解耦，解决单体应用扩展性的问题。
进入微服务之后，解决了集中式架构的单体应用很多问题，但是新的问题应运而生。
微服务的粒度应该多大 ？
微服务如何设计？
微服务如何拆分 ？
微服务边界在哪里 ？
很长时间人们都没有解决这一问题，就连Martin Fowler在提出微服务架构的时候也没有告诉我们这该如何拆分微服务。
甚至在很长的时间里人们对微服务拆分产生了一些误解，有人认为："微服务很简单，就是将之前的单体应用拆分成多个部署包，或者将原来的单体应用架构替换为一套支持微服务的技术架构，就算是微服务了。" 还有人认为微服务应该拆分得越小越好。
鉴于上述情形，很多项目因为前期拆分过度，导致复杂度过高，导致后期难以运维甚至难以上线。
可以得出一个结论：微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。而DDD就是解决了这个确定业务边界的问题，它并不是一种技术架构，而是一种划分业务领域范围的方法论，用DDD的思路进行业务梳理可以很好规划服务边界，实现微服务内部和外部的"高内聚、低耦合"。
那么，什么是DDD呢？
DDD（领域驱动设计），起源于2004年Eric Evans出版《领域驱动设计》，近些年由于微服务的兴起，大家逐渐对单体服务进行拆分。
DDD是一种拆解业务、划分业务、确定业务边界的方法，是一种高度复杂的领域设计思想，将我们的问题拆分成一个个的域， 试图分离技术实现的复杂性，主要解决的是软件难以理解难以演进的问题，DDD不是一种架构，而是一种架构方法论，目的就是将复杂问题领域简单化，帮助我们设计出清晰的领域和边界，可以很好的实现技术架构的演进。
DDD包括两部分，战略设计部分和战术设计部分。
战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
DDD战略设计会建立领域模型，通俗来说就是模拟某个领域的的一种模型，这个模型比较抽象，便于理解，举个例子：公园有一棵桃树，如果我们想好好研究桃树该怎么研究？
桃子好吃吗？贵不贵？什么品种？怎么种植？种在什么地方？做成桃木剑？桃子树叶药用价值？这样研究每一个问题都很有道理，但是又很混乱，那我们该怎么来研究呢？
先将植物根据大家的理解分成多个器官，像桃子、桃叶、桃花等等，然后将每一个器官再根据功能细分成组织，再根据这些组织中各个细胞形态等作用分成不同的细胞，这样就会条理清晰。
DDD也是如此，当我们面对如桃树这种复杂的业务的时候，先根据固有的认识分成多个器官(领域)，然后再在每一个领域中根据某些维度(这部分是功能)分为多个组织(聚合)，而每一个组织中由很多细胞(实体)组成，这就是一种战略。
DDD战略设计会建立领域模型，领域模型用来指导微服务的设计和拆分DDD第一步要做的就是对业务的理解，主要目的就是尽可能不遗漏的分解我们的业务领域，就好比刚刚的桃树，最先要做的就是尽可能多的分析，确保每一个领域都可以被关注到，在实践中，往往会采用用例分析、场景分析和用户旅程分析，这是一个发散的过程，此阶段会产生很多实体、命令、事件等领域对象，我们从不同的维度对进行聚类形成聚合、限界上下文等边界，建立领域模型，这是一个收敛的过程。
具体来说， 我们可以通过三步来确定领域模型和微服务边界。
1、在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
2、根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。
3、根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。
