对ddd和微服务的理解

首先DDD(领域驱动设计)是啥？

它其实是一种思想，处理高度复杂领域的设计思想， 说白了就是架构设计的方法。 但是我们做架构设计并不简单，通常和会各种复杂的业务相交合，单从技术角度，产品角度，业务角度触发所产生的思想都五花八门，很难去设计出最适合公司或者某个产品的架构。而ddd在这里就涉及到一个很重要的概念—领域。

ddd诞生的初衷就是为了能做到复杂领域简单化清晰化，为了使业务更加清晰，技术实现更加可靠，首先ddd用于分离技术实现的复杂性，围绕我们平时接触到的业务概念来构建不同的领域模型，将复杂领域简单化 ，设计出清晰的领域和应用边界，使架构设计更容易。

架构设计的过程

最开始我们开始做架构设计都是从数据库和字段开始，直接面对的是客户端ui层,这种叫两层单机架构，有点类似于面向过程的设计。

后来我们开始分层次设计，比如业务接入层，业务逻辑层，数据访问层和数据库。就是很常见的mvc架构和面向服务的soa架构。这种设计的好处就是层次分明，但是一旦业务复杂容易使系统臃肿，业务与业务板块耦合性非常高，不方便扩展和弹性伸缩。

然后就是分布式微服务架构，主要就是为了实现应用之间的解耦，团队的敏捷开发，还有高扩展高可用的设计理念。但是提到微服务，就要说一下他的颗粒度拆分，估计是我们平时做设计的时候最大的难点。

微服务拆分

微服务拆分困境根本原因就是不知道业务的边界在什么地方，首先确认边界就能解决我们拆分微服务的难点。ddd的设计方法是怎么做的呢。第一个建立领域模型，第二划分领域边界，然后再根据我们划分的领域边界从咱们业务的视角再去划分微服务边界。ddd设计出的微服务的业务和应用边界都很清晰，通过这样子就很好的实现微服务内部和外部的高内聚，低耦合。

战略设计与战术设计

ddd经常会提到战略设计和战术设计， 两者的目的一样但是出发点不一样。战略设计就是从业务角度出发，先建立领域模型，划分领域边界，建立上下文边界就也是我们微服务设计边界。然后战术设计是从我们技术视角出发，基于领域模型的技术实现，完成我们的开发工作。

ddd的领域，子域，核心域，支撑域，通用域

从我们建立领域模型到微服务的细分，开发，整个是一气呵成，领域的核心思想就是将业务问题逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题，构建合适的领域模型，而领域模型映射成系统就是微服务了。我们怎么来建立领域模型呢？领域里面又包含子域，核心域，通用域，支撑域，这些都是概念，举个以前开发的例子，商城管理系统。商城就是领域，一个商城可以分为用户，订单，商品等服务这些都是子域。子域可以根据自身的重要性跟功能属性划分为核心子域，支撑子域跟通用子域。核心子域要具体分析。比如订单服务，相对于商品来说就是核心的子域，基础商品是支撑子域。但我们要下单首先得登陆，登陆需要鉴权认证比如jwt认证，这类服务就是通用的属于通用子域。每个子域的划分就看这个子域基于产品或者公司的定位和重要性，重要性最高的并且是公司的核心就是核心域。

语义环境上下文拆分

从我们提出一个新需求到落地的过程：

1、首先建立通用语言。就是大家各个部门都能听懂的语言，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言。 领域负责人，产品设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语。

2、构建领域对象。通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。

3、代码开发落地。微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。

比如说请假流程，请假就是个领域，在这个领域一定要保证上下文的思想统一，比如请假条就是拿来做请假记录的作用，如果理解成其他意思，那就说明业务语言没统一。然后请假包含请假单，创建请假信息，创建审批轨迹信息等，细分分成这种领域服务这样子就能和微服务映射了。

上下文边界

我们大家定义的语言离不开它的语义环境。而业务的通用语言就有它的业务边界，我们不怎么可能用一句简单的话，没有歧义地去描述一个复杂的业务领域。上下文边界就是用来细分这些领域的，从而定义通用语言所在的边界。对于同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为微服务设计的边界

通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由上下文边界来限定的，以确保语义的唯一性。

微服务与上下文边界

而领域专家、架构师和开发人员的主要工作就是通过业务来划分上下文边界。上下文的边界确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等其它外部因素，一个上下文边界理论上就可以设计为一个微服务。

可以说，上下文边界在微服务设计中具有很重要的意义，如果上下文边界的方向偏离，那微服务的设计结果也就可想而知了。因此，我们只有理解了上下文边界的真正涵义以及它在微服务设计中的作用，才能真正发挥ddd的价值，这是ddd基础也是前提。

上下文的边界就是是微服务设计和拆分依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个上下文边界就可以设计为一个微服务。

大概说了一下我对ddd，微服务设计和拆分的理解。通过 DDD 战略设计可以建立领域模型，划定领域边界，解决微服务设计过程中，边界难以划定的难题。特别是我们业务焦点在领域和领域逻辑，那么我们就可以选择 DDD 作为微服务的设计方法！当然ddd设计这块还有很多，比如怎么设计实体和值对象，聚合之类的ddd模型概念，我可能理解的并不是完全正确，希望自己再接再励，为自己的架构知识铺上厚厚路，共同进步。