(2) 基于领域分析设计的架构规范-领域分析基础

本系列目录：

1. 改变与优点
2. 领域分析基础
3. 读写隔离
4. 充血模型之实体
5. 充血模型之Service
6. 关于重构与落地

因为整个架构规范很大程度上是基于领域驱动设计（Domain Driven Design,DDD）的思惟，因此，有必要在这里和你们先介绍一下DDD的一些概念。

领域聚合

让咱们用一个相对简单的小电商系统来举例，来讲明几个概念，这个电商系统的大概需求以下

• 咱们主营的商品是甜品，计划让用户能过经过微信小程序来完成下单到支付的整个流程
• 用户可以在咱们的小程序主页选择甜品主食，而后选择详细的一些辅料搭配，最终下单，（为了简化，暂不考虑购物车，也就是一单只有一个甜品）
• 目前只容许堂食，不考虑配送
• 对了，咱们偶尔还会须要派发一些优惠券，用户能在支付的时候输入优惠券进行抵扣（一次最多用一张）
• 咱们想可以记录好每一个用户从下单，支付，到制做完成的整个流程记录

而后，咱们可以很快得出这样一个模型图

简单来讲就是：

• 一个用户能够建立多个订单，固然也能够不下单
• 一个订单会产生至少一条订单变动记录（从建立开始）
• 一个订单只对应一种商品，假定商品的“辅料搭配”只做为一个“备注”属性存储到商品
• 一个订单最多使用一张优惠券，而优惠券，当时能够一直不被使用

若是这个时候问你 你以为那两个模型类的相互关系是最紧密的呢？ 相信几乎你们对这个答案没有异议

可能你这时说不上来缘由，但至少从直觉来看，你们都会这么选择，并且确实也是如此

由于这是一个聚合——订单聚合。

他们的关系很紧密，有多紧密？若是必定要挑一个最重要的因素来讲，就是：订单变动记录不能离开订单而单独存在。对，他们必须在一块儿，并且订单是中心，变动记录是它的旁支。若是订单不存在了，或者不指定某一个订单，那么这个变动记录则毫无心义。

其中，Order被称之为聚合根(Aggregate Root)，或者根实体(Root Entity)。全部的行为都从订单出发，而相似订单变动记录这种非根实体，则不直接与外界打交道。

那优惠券呢？优惠券不也只能用于订单吗？它不该该属于"订单的优惠券”吗？

并不会，由于优惠券能够停留在不被使用的状态，在那时，它是脱离订单而存在的，并且咱们能够在不须要外界任何其余领域的状况下，直接对优惠券进行一些设置修改，这也说明了，它是一个独立的领域，或者说独立的聚合存在

至于分析出来的目的，在充血模型一章咱们再详细说明。

分层模型

下图为《领域驱动设计》中所提到的分层架构

关于原书对四层的介绍，我在这里先不原文复述了，我以个人理解（或疑问），分别挑选重点进行介绍：

用户界面层

其实这里有些困惑，我不知道做者是否将前端应用也包含进来。若是没有，那么这里可能就相似咱们说的网关，或者路由配置层之类。不过总之，这里并非领域分析的重点。

应用层

这是一个和领域层的界限相对模糊的一层。在原书中，这一层的描述是这样：

定义软件能够完成的工做....它不包含处理业务规则或知识，只是给下一层中相互协做的领域对象协调任务、委托工做。

“定义软件能够完成的工做”，咱们能够理解这是一个应用服务的入口，一个功能单元，一个API，那么，以SpringMVC为例，那么咱们开发时入口是什么？天然是@Controller，若是须要事务支持，就在这里加上@Transactional也没问题，千万不要认为事务不加在@Service上就感受怪怪的，没什么好奇怪的，要摆脱这种思惟惯性。

“它不包含处理业务规则或知识”，并不是彻底“和业务无关”。广义上来讲，连一个商业项目的整个架构都是为业务来服务，就算是遵循了“开闭原则”，保证了“扩展性”，依旧是以业务方向作主导。因此，应用层也会涉及业务，可是却非“核心逻辑”。那如何界定？我目前也没有想到一个能够简单描述出来的说法，只是作了一些相对简单粗暴的规定：若是这个功能要求用到一些公共的组件，诸如文件上传下载，EXCEL/WORD等文件解析等明显是工具型作法，通常来讲都能放在这一层。

领域层

核心业务逻辑，以后咱们讨论的主要内容都在这一层。

基础设施层

持久化读写，公共组件如上面提到的文件下载工具等，还有好比RPC的框架组件等等，都属于此层。这一层能够被上面的任何一层直接调用

全部层容许调用下方层，反之则否则

下一篇：读写隔离