领域驱动设计-DDD介绍
架构的演进
我们先看一下三种技术架构的演进以及主要区别：
第一阶段是单机架构，特征是整个开发围绕着数据库进行设计和开发。
第二个阶段是三层式的集中式架构，采用面向对象的设计方法，业务逻辑分业务层、逻辑层、数据访问层，这种架构很容易某一层或者几层变得臃肿，扩展性较差， 另外摩尔定律失效， 单台机器性能有限。
第三层阶段是微服务架构，在集中式架构中， 系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，那么就涉及到交流信息丢失的问题， 另外项目从分析到开发经历的流程很长，很容易最终开发设计与需求实现的不一样，微服务主要就是解决第二阶段的这些痛点，实现应用之间的解耦，解决单体应用扩展性的问题。
微服务存在的问题 -
进入微服务之后 ， 解决了集中式架构的单体应用很多问题， 但是新的问题应运而生 ， 微服务的粒度应该多大 ？微服务如何设计呢？微服务如何拆分 ？微服务边界在哪里 ？
很长时间人们都没有解决这一问题，就连Martin Fowler在提出微服务架构的时候也没有告诉我们这该如何拆分微服务。
甚至在很长的时间里人们对微服务拆分产生了一些误解， 有人认为："微服务很简单，就是将之前的单体应用拆分成多个部署包， 或者将原来的单体应用架构替换为一套支持微服务的技术架构，就算是微服务了。" 还有人认为微服务应该拆分得越小越好。
鉴于上述情形， 很多项目因为前期拆分过度， 导致复杂度过高， 导致后期难以运维甚至难以上线。
可以得出一个结论：微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。
而DDD就是解决了这个确定业务边界的问题，可见DDD并不是一种技术架构，而是一种划分业务领域范围的方法论。DDD的兴起是由于很多熟悉领域驱动建模(DDD)的工程师在进行微服务设计时， 发现用DDD的思路进行业务梳理可以很好规划服务边界， 可以很好实现微服务内部和外部的"高内聚、低耦合"。于是越来越多的人将DDD作为业务划分的指导思想。
那么，什么是DDD呢？
DDD 的概述
通过上文的学习就可以知道DDD是一种拆解业务、划分业务、确定业务边界的方法， 是一种高度复杂的领域设计思想，将我们的问题拆分成一个个的域，试图分离技术实现的复杂性，主要解决的是软件难以理解难以演进的问题，DDD不是一种架构， 而是一种架构方法论，目的就是将复杂问题领域简单化，帮助我们设计出清晰的领域和边界，可以很好的实现技术架构的演进。
DDD包括两部分，战略设计部分和战术设计部分：
战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
战略设计
关键概念
子域
DDD的第一件事情，就是找到不同的语境， 划分子域，子域可以继续划分为更细的粒度的子域
子域类型
核心域：业务成功的主要因素和公司的核心竞争力，资源需要重点投入，如：电商的交易、物流、CRM
支撑子域：有定制开发需求，可以考虑外包，如：很多公司的 CRM、ERP
通用子域：没有定制开发需求，可以考虑采购现成的，如：人事管理系统
开源or自研：什么时候应该自研，什么时候应该使用开源？同一个名词，不同的业务人员/业务团队，理解可能完全不同
限界上下文
限界上下文是子域对应的解决方案空间概念,一个子域会对应一个限界上下文。但是在DDD的概念里经常混用，限界上下文也经常作为问题空间概念使用
限界上下文的边界也是通用语言UL的边界，限界上下文等于一个语言的边界
通常情况下一个微服务对应一个限界上下文
上下文映射
上下文映射表示两个限界上下文之间的集成关系以及团队间的动态关系，
