DDD为什么能火起来？和微服务有啥关系？
DDD为什么能火起来？
我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。
第一阶段是单机架构，特征是整个开发围绕着数据库进行设计和开发。 第二个阶段是三层式的集中式架构，采用面向对象的设计方法，业务逻辑分业务层、逻辑层、数据访问层，这种架构很容易某一层或者几层变得臃肿，扩展性较差， 另外摩尔定律失效， 单台机器性能有限。
第三层阶段是微服务架构，在集中式架构中， 系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，那么就涉及到交流信息丢失的问题， 另外项目从分析到开发经历的流程很长，很容易最终开发设计与需求实现的不一样，微服务主要就是解决第二阶段的这些痛点，实现应用之间的解耦，解决单体应用扩展性的问题。 微服务存在的问题
进入微服务之后 ， 解决了集中式架构的单体应用很多问题， 但是新的问题应运而生 ， 微服务的粒度应该多大 ？微服务如何设计呢？微服务如何拆分 ？微服务边界在哪里 ？
很长时间人们都没有解决这一问题，就连Martin Fowler在提出微服务架构的时候也没有告诉我们这该如何拆分微服务。
甚至在很长的时间里人们对微服务拆分产生了一些误解， 有人认为："微服务很简单，就是将之前的单体应用拆分成多个部署包， 或者将原来的单体应用架构替换为一套支持微服务的技术架构，就算是微服务了。" 还有人认为微服务应该拆分得越小越好。
鉴于上述情形， 很多项目因为前期拆分过度， 导致复杂度过高， 导致后期难以运维甚至难以上线。另外，微服务系列面试题和答案全部整理好了，微信搜索互联网架构师，在后台发送：2T，可以在线阅读。
可以得出一个结论：微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。 而DDD就是解决了这个确定业务边界的问题，可见DDD并不是一种技术架构，而是一种划分业务领域范围的方法论。DDD的兴起是由于很多熟悉领域驱动建模(DDD)的工程师在进行微服务设计时， 发现用DDD的思路进行业务梳理可以很好规划服务边界， 可以很好实现微服务内部和外部的"高内聚、低耦合"。于是越来越多的人将DDD作为业务划分的指导思想。 那么，什么是DDD呢？ DDD概述
通过上文的学习就可以知道DDD是一种拆解业务、划分业务、确定业务边界的方法， 是一种高度复杂的领域设计思想，将我们的问题拆分成一个个的域， 试图分离技术实现的复杂性，主要解决的是软件难以理解难以演进的问题，DDD不是一种架构， 而是一种架构方法论， 目的就是将复杂问题领域简单化， 帮助我们设计出清晰的领域和边界， 可以很好的实现技术架构的演进。DDD包括两部分，战略设计部分 和 战术设计部分 战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。 战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
DDD战略设计会建立领域模型， 这四个字放一起会让人觉得很高深， 其实是纸老虎， 通俗来说就是模拟某个领域的的一种模型， 这个模型比较抽象， 但便于人们交流， 举个例子：公园有一棵桃树， 如果我们想好好研究桃树该怎么研究 ？ 桃子好吃吗？贵不贵？品种？怎么种植？种在什么地方 ？做成桃木剑？桃子树叶药用价值？
你看， 这样研究每一个问题都很有道理， 但是又很混乱，再回忆一下初中生物书上是这么研究的？，微信搜索公众号互联网架构师，在后台发送：2T，送你一份惊喜礼包。
先将植物根据大家的理解分成多个器官组成， 像桃子、桃叶、桃花等等， 然后将每一个器官再根据功能细分成组织， 再根据这个组织中各个细胞的形态等作用分成不同的细胞， 你看看这是不是一种很有条理的分析方法。
DDD也是如此， 当我们面对桃树这种复杂的业务的时候，先根据固有的认识分成多个器官(领域)，然后再在每一个领域中根据某些维度(这儿是功能)分为多个组织(聚合)， 而每一个组织中由很多细胞(实体)组成，这就是一种战略， 有哪些好处呢 ？
可以确保我们讨论的边界， 也就是讨论的东西是一个领域一个维度的， 对于桃树来说， 桃子 、桃花、桃叶、树干都是不同的领域， 划分不同领域的就是边界， 我们这儿叫领域边界， 当我们确定好这些领域之后， 就可以确保我们讨论的是同一个领域部分的东西，这样的好处就是我们可以规定好一些概念， 或者说术语， 以后大家讨论的时候就尽可能少的信息丢失。
DDD战略设计会建立领域模型 ， 领域模型用来指导微服务的设计和拆分， DDD第一步要做的就是来一个头脑风暴， 可以理解成一起讨论对业务的理解 ， 主要目的就是尽可能前面不遗漏的分解我们的业务领域， 就好比刚刚的桃树， 最先要做的就是尽可能多的分析， 确保每一个领域都可以被关注到。
在实践中 ，往往会采用用例分析、场景分析和用户旅程分析， 这是一个发散的过程，头脑风暴阶段会产生很多实体、命令、事件等领域对象， 我们从不同的维度对进行聚类形成聚合、限界上下文等边界，建立领域模型， 这是一个收敛的过程。
具体来说， 我们可以通过三步来确定领域模型和微服务边界。
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
总结
这篇文章主要研讨了DDD火起来的原因， 解决了什么业界难题， 知道DDD主要思路 ， 以及DDD大概的实现步骤等 。 留个小问题：单体应用适合DDD吗？
