前边两篇，我们讲述为什么用DDD？DDD如何做好需求梳理？理解了DDD要达到的目标，需求梳理好，达成统一语言了。那么接下来，就是这些需求的落地了。那么落地的第一步是什么？这些需求做在什么地方（系统）。这也是DDD划分的核心思想，自顶向下，由大到小，将其放到最合理的地方。好，先看下思维导图：
这篇我们重点说三个点：限界上下文，上下文映射和领域架构。
一，限界上下文（Bounded Context）,其实在上一篇需求分析中，重点提出的一点“统一语言”，其实就是针对限界上下文中，有其大家都认可的通用语言。Spring Context大家应该都知道吧，说的是spring容器的上下文。而Bounded Context是指某一业务领域的上下文。看一下其它对其的定义：
限界上下文是一个显示的边界，领域模型便存在于边界之内。在边界之内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。
用来封装通用语言和领域对象，提供上下文环境，保证领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的使用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
好，我们再看张图：
限界上下文，我们理解一下，限界就是领域的边界，上下文就是语义环境。例如上边的“购买上下文”、“库存上下文”。其实就是一个有边界的业务范围。例如在购买上下文，就表示购买这个业务的业务范围领域。其中在库存上下文中的货品，在这里就成了商品。购买上下文中，有购买业务领域一套通用语言，负责购买业务领域的各种功能。再说通俗一点，如果只在业务领域角度思考的话，我认为理论上，限界上下文就可以对应我们的微服务系统了。进而引入其几个特点：最小完备、稳定空间、自我履行、独立进化。
二，上下文映射：顾名思义就是上下文的关联关系，反应到微服务就是微服务与微服务彼此之间的关系。看下这个图：
关系在微服务之间，无在乎这么几种：没关系，影响，依赖。这也是耦合程度越来越重。而软件设计一直追求的是高内聚、低耦合，方便业务的迭代进化。好，下边我们来看软件服务之间的几种上下文映射模型：合作关系（Partnership）、共享内核（Shared Kernel）、客户方-供应方开发（Customer-Supplier Development）、尊奉者（Conformist）、防腐层（Anticorruption Layer）、开放主机服务（Open Host Service）、发布语言（Published Language）、另谋出路（SeparateWay）、大泥球（Big ball of Mud）（前边一篇文章有总结过：《DDD领域驱动——限界上下文的关系》），这里看下图，理解一下（D：Downstream-下游；U：Upstream-上游；OHS：Open host server；ACL：access contral lists）：
三，领域架构：也就是指一个微服务系统的架构，传统我们往往是三层架构：view展示层、service业务逻辑层、dao数据操作层，后来前后端分离后，我们经常用controller业务控制层、service业务处理层、dao数据操作层，当然在工作中我也见过很多，对不同的功能进行划分归来的，例如until，前置层，sftp、redis、mq等操作层。其实归根结底就是划分，和微服务纵向拆分一样，把复杂的事通过拆分变成高内聚低耦合的功能单元。好我们看下DDD中微服务架构的几种体现形式（根据实际情况而定，本质是通过拆分，形成高内聚低耦合的闭环功能单元）
一，菱形对称架构图：
说明：菱形对称架构核心是，请求request从上（北向网关）到下（南向网关），OHS北向网关（包括remote远程服务层：例如providers-RPC提供服务，Event Subscribers-事件订阅，controllers-http服务等；local本地服务层，对领域层的封装整合等）；Domain Layer（领域层-核心业务的处理层）；ACL南向网关（数据操作层、各种client处理，事件的发布处理等，再加一层各种功能适配接口层）
二，整洁架构：
说明：整洁架构通过图片可以看出，处理最核心的业务实体在最里边，能够保证其高内聚，所有的操作都是从外层，一层层向里边访问处理。
三，四层架构
说明：用户接口层对外提供服务，应用层整合领域层服务，领域层做核心业务处理，基础层做基础功能封装。
架构可以映射到我们微服务代码的包路径，通过包进行划分层层之间的划分。但是这几种架构只是一种展示形式。记住本质是：将复杂的功能拆分成井井有条的高内聚功能单元。在有指导思想和规则的基础上，根据实际情况灵活应变。
好，这篇主要总结了限界上下文、上下文映射、领域架构。其实就是微服务如何进行划分、微服务和微服务之间的关系、微服务系统如何分层。核心总结：DDD通过领域抽象，自顶向下合理的划分将复杂的功能拆分为高内聚的功能单元。达到领域核心业务处理的稳定，以不变应万变的目标。