我们先不讨论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大概的实现步骤等。原文链接：https://www.cnblogs.com/Courage129/p/14839544.html
—————END—————
干货|如何步入Service Mesh微服务架构时代
实战|Service Mesh微服务架构实现服务间gRPC通信
再见Nacos，我要玩Service Mesh了！
玩转Service Mesh微服务熔断、限流骚操作
Kubernetes微服务自动化发布系统
Kubernetes微服务监控体系
Kubernetes集群搭建超详细总结(CentOS版)
Kubernetes学习环境难搭建？Mac笔记本上安装一个！
