共计 3147 个字符，预计需要花费 8 分钟才能阅读完成。
DDD 为什么能火起来？
咱们先不探讨 DDD 的定义，先梳理一下 DDD 火起来的背景，依据我学习的套路，永远是为什么为先，再是解决什么问题，是什么货色，最初如何应用。咱们都晓得这些年随着设施以及技术的倒退，软件架构产生了很多变动，从最后的单机（BS/CS）架构到前面的集中式架构，再到现在的微服务架构，当初根本能够说是微服务架构流行的时代，DDD 早在 2004 年就由埃里克·埃文斯提出，但始终处于一个不愠不火的状态，直到 Martin Fowler 的《Microservices》引起大家留神，也就是微服务流行之后（这儿须要阐明的是，微服务最早的提出者不是 Martin Fowler，而是 Fred George），DDD 再次回到人们视线两头，为什么呢？
咱们先看一下三种技术架构的演进以及次要区别：
第一阶段是单机架构，特色是整个开发围绕着数据库进行设计和开发。
第二个阶段是三层式的集中式架构，采纳面向对象的设计办法，业务逻辑分业务层、逻辑层、数据拜访层，这种架构很容易某一层或者几层变得臃肿，扩展性较差，另外摩尔定律生效，单台机器性能无限。
第三层阶段是微服务架构，在集中式架构中，系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，那么就波及到交流信息失落的问题，另外我的项目从剖析到开发经验的流程很长，很容易最终开发设计与需要实现的不一样，微服务次要就是解决第二阶段的这些痛点，实现利用之间的解耦，解决单体利用扩展性的问题。
微服务存在的问题
进入微服务之后，解决了集中式架构的单体利用很多问题，然而新的问题应运而生，微服务的粒度应该多大？微服务如何设计呢？微服务如何拆分？微服务边界在哪里？
很长时间人们都没有解决这一问题，就连 Martin Fowler 在提出微服务架构的时候也没有通知咱们这该如何拆分微服务。
甚至在很长的工夫里人们对微服务拆分产生了一些误会，有人认为：“微服务很简略，就是将之前的单体利用拆分成多个部署包，或者将原来的单体利用架构替换为一套反对微服务的技术架构，就算是微服务了。”还有人认为微服务应该拆分得越小越好。
鉴于上述情景，很多我的项目因为后期拆分适度，导致简单度过高，导致前期难以运维甚至难以上线。
能够得出一个论断：微服务拆分窘境产生的根本原因就是不晓得业务或者微服务的边界到底在什么中央。换句话说，确定了业务边界和利用边界，这个窘境也就迎刃而解了。
而 DDD 就是解决了这个确定业务边界的问题，可见 DDD 并不是一种技术架构，而是一种划分业务畛域范畴的方法论。DDD 的衰亡是因为很多相熟畛域驱动建模 (DDD) 的工程师在进行微服务设计时，发现用 DDD 的思路进行业务梳理能够很好布局服务边界，能够很好实现微服务外部和内部的“高内聚、低耦合”。于是越来越多的人将 DDD 作为业务划分的指导思想。
那么，什么是 DDD 呢？
DDD 概述
通过上文的学习就能够晓得 DDD 是一种拆解业务、划分业务、确定业务边界的办法，是一种高度简单的畛域设计思维，将咱们的问题拆分成一个个的域，试图拆散技术实现的复杂性，次要解决的是软件难以了解难以演进的问题，DDD 不是一种架构，而是一种架构方法论，目标就是将简单问题畛域简单化，帮忙咱们设计出清晰的畛域和边界，能够很好的实现技术架构的演进。DDD 包含两局部，策略设计局部和战术设计局部。
策略设计次要从业务视角登程，建设业务畛域模型，划分畛域边界，建设通用语言的限界上下文，限界上下文能够作为微服务设计的参考边界。
战术设计则从技术视角登程，侧重于畛域模型的技术实现，实现软件开发和落地，包含：聚合根、实体、值对象、畛域服务、应用服务和资源库等代码逻辑的设计和实现。
DDD 策略设计会建设畛域模型，这四个字放一起会让人感觉很浅近，其实是纸老虎，艰深来说就是模仿某个畛域的的一种模型，这个模型比拟形象，但便于人们交换，举个例子：公园有一棵桃树，如果咱们想好好钻研桃树该怎么钻研？
桃子好吃吗？贵不贵？种类？怎么种植？种在什么中央？做成桃木剑？桃子树叶药用价值？
你看，这样钻研每一个问题都很有情理，然而又很凌乱，再回顾一下初中生物书上是这么钻研的？
先将动物依据大家的了解分成多个器官组成，像桃子、桃叶、桃花等等，而后将每一个器官再依据性能细分成组织，再依据这个组织中各个细胞的状态等作用分成不同的细胞，你看看这是不是一种很有条理的分析方法。
DDD 也是如此，当咱们面对桃树这种简单的业务的时候，先依据固有的意识分成多个器官（畛域），而后再在每一个畛域中依据某些维度 (这儿是性能) 分为多个组织（聚合），而每一个组织中由很多细胞（实体）组成，这就是一种策略，有哪些益处呢？能够确保咱们探讨的边界，也就是探讨的货色是一个畛域一个维度的，对于桃树来说，桃子、桃花、桃叶、树干都是不同的畛域，划分不同畛域的就是边界，咱们这儿叫畛域边界，当咱们确定好这些畛域之后，就能够确保咱们探讨的是同一个畛域局部的货色，这样的益处就是咱们能够规定好一些概念，或者说术语，当前大家探讨的时候就尽可能少的信息失落。
DDD 策略设计会建设畛域模型，畛域模型用来领导微服务的设计和拆分，DDD 第一步要做的就是来一个头脑风暴，能够了解成一起探讨对业务的了解，次要目标就是尽可能后面不脱漏的合成咱们的业务畛域，就好比刚刚的桃树，最先要做的就是尽可能多的剖析，确保每一个畛域都能够被关注到，在实践中，往往会采纳用例剖析、场景剖析和用户旅程剖析，这是一个发散的过程，头脑风暴阶段会产生很多实体、命令、事件等畛域对象，咱们从不同的维度对进行聚类造成聚合、限界上下文等边界，建设畛域模型，这是一个收敛的过程。
具体来说，咱们能够通过三步来确定畛域模型和微服务边界。
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及内部依赖关系等，依据这些因素梳理出畛域实体等畛域对象。
第二步：依据畛域实体之间的业务关联性，将业务严密相干的实体进行组合造成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线示意。
第三步：依据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，造成畛域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是将来微服务的边界，不同限界上下文内的畛域逻辑被隔离在不同的微服务实例中运行，物理上互相隔离，所以是物理边界，边界之间用实线来示意。
下面除了畛域、聚合、实体外还呈现了聚合根、值对象等词语，除此之外还有对立建模语言、子域、外围域、通用域、撑持域等，其实都是纸老虎，后面说过了为了不便对于某个畛域的探讨往往会造成一些概念，这些概念会有一些名词概括，下面的名词就是这么来的，这就叫对立建模语言，哈哈哈，好了，不扯淡，我前面的文章会解释下这些词语的意思，这儿次要探讨 DDD 解决什么了问题。
梳理一下 DDD 与微服务的关系，DDD 是一种架构设计办法，微服务是一种架构格调，两者从实质上都是为了谋求高响应力，而从业务视角去拆散利用零碎建设复杂度的伎俩。两者都强调从业务登程，其外围要义是强调依据业务倒退，正当划分畛域边界，继续调整现有架构，优化现有代码，以放弃架构和代码的生命力，也就是咱们常说的演进式架构。DDD 次要关注：从业务畛域视角划分畛域边界，构建通用语言进行高效沟通，通过业务形象，建设畛域模型，维持业务和代码的逻辑一致性。
注：运行时的过程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
最初总结
这篇文章次要研究了 DDD 火起来的起因，解决了什么业界难题，晓得 DDD 次要思路，以及 DDD 大略的实现步骤等。
留个小问题：单体利用适宜 DDD 吗？
