DDD领域驱动架构的初步总结与思考

[TOC]

参考了知乎上的一篇文章:https://www.zhihu.com/question/25089273，总结和学习领域驱动的架构.

基本场景

客户买手机场景，不同的店员需要记录订单信息，用于如下几种场景使用：

客人咨询时可以快速查到。
店员A做记录
老板查看记录。

统一起来的信息，比如这个场景中的商品订单：客户信息（姓名+电话等） + 商品信息，就是心智模型（mental model）。

数据模型（data model），则是对这些信息进行标准化，如长度、内容等，这个过程叫做数据建模（data modeling）。

建模的本质

建模的本质是归类和抽象，有两个目的：

提取心智模型，显性化的统一不同人对业务的理解。
是为了归类复用。

DDD的概念

DDD是Eric Evans在2003年出版的《领域驱动设计：软件核心复杂性应对之道》（Domain-Driven Design: Tackling Complexity in the Heart of Software）一书中提出的具有划时代意义的重要概念，是指通过统一语言、业务抽象、领域划分和领域建模等一系列手段来控制软件复杂度的方法论。

DDD 把模型分成四层。

UI 层，负责界面展示。
应用层（Application Layer），负责业务流程。
领域层（Domain Layer），负责领域逻辑。
基建层（Infrastructure Layer），负责提供基建。

DDD的理解

我个人理解，针对上述的场景，应该做如下划分：

UI层是具体的客户查询、店员查询、老板查询的不同的UI界面。
应用层是，订单记录、订单查询的标准外部接口。
领域层是，标准订单查询服务、标准下单服务、标准客户建立服务、标准客户查询服务
基建层是，服务的具体实现，如使用mysql、redis等各种层面的处理。

领域层与应用层的切分

这里面最难以区分的应该是应用层与领域层的切分了，为什么DDD现在火热起来，与微服务的概念不谋而和。通过DDD模型来映射，原来的怎么拆分服务与微服务就变成了怎么拆分应用层与领域层，然后再套用DDD的理论对领域和应用的切分做规定。

领域模型对应的领域逻辑如下理解：

共识，领域逻辑是显性的专业知识，是领域内的常识或者共识，比较容易的理解和符合逻辑。
合规，领域逻辑是提纯的通用规则，他有内部的完整的一套自洽的流程，是符合领域规则的。

应用层的理解如下：

要负责多个领域之间的流程调度，流程的调度要符合合理性。
应用层不应该管具体的实行细节。

领域层不应该负责的是流程以及合理性，比如收银员下架货品的场景，应该做如下切分：

领域层：

货品下架，负责检查仓库是否有足够位置，将货品从商场转移到仓库的全过程。不负责这个操作是否合理，是判断这个操作是否合规。

应用层：

通过流程来调度多个领域如黑名单、收银员权限、货品下架领域来操作。应用层来判断这个操作是否合理。