由于整个架构规范很大程度上是基于领域驱动设计（Domain Driven Design,DDD）的思维，所以，有必要在这里和大家先介绍一下DDD的一些概念。
领域聚合
让我们用一个相对简单的小电商系统来举例，来说明几个概念，这个电商系统的大概需求如下
- 我们主营的商品是甜品，计划让用户能过通过微信小程序来完成下单到支付的整个流程
- 用户能够在我们的小程序主页选择甜品主食，然后选择详细的一些辅料搭配，最终下单，（为了简化，暂不考虑购物车，也就是一单只有一个甜品）
- 目前只允许堂食，不考虑配送
- 对了，我们偶尔还会需要派发一些优惠券，用户能在支付的时候输入优惠券进行抵扣（一次最多用一张）
- 我们想能够记录好每个用户从下单，支付，到制作完成的整个流程记录
然后，我们能够很快得出这样一个模型图
简单来说就是：
- 一个用户可以创建多个订单，当然也可以不下单
- 一个订单会产生至少一条订单变更记录（从创建开始）
- 一个订单只对应一种商品，假定商品的“辅料搭配”只作为一个“备注”属性存储到商品
- 一个订单最多使用一张优惠券，而优惠券，当时可以一直不被使用
如果这个时候问你 你觉得那两个模型类的相互关系是最紧密的呢？ 相信几乎大家对这个答案没有异议
可能你这时说不上来原因，但至少从直觉来看，大家都会这么选择，而且确实也是如此
因为这是一个聚合，订单聚合 他们的关系很紧密，有多紧密？如果一定要挑一个最重要的因素来说，就是：“订单变更记录不能离开订单而单独存在” 对，他们必须在一起，而且订单是中心，变更记录是它的旁支。如果订单不存在了，或者不指定某一个订单，那么这个变更记录则毫无意义
其中，Order被称之为聚合根(Aggregate Root)，或者根实体(Root Entity)。所有的行为都从订单出发，而类似订单变更记录这种非根实体，则不直接与外界打交道。如果暂时不太好理解，等到之后我们讲到充血模型的时候会有详细说明。
那优惠券呢？优惠券不也只能用于订单吗？它不应该属于"订单的优惠券”吗？ 并不会，因为优惠券可以停留在不被使用的状态，在那时，它是脱离订单而存在的，而且我们可以在不需要外界任何其他领域的情况下，直接对优惠券进行一些设置修改，这也说明了，它是一个独立的领域，或者说独立的聚合存在
至于现在分析出来有什么用，这就和之后提到的充血模型设计理念有关了，暂时先不扩展
分层模型
下图为《领域驱动设计》中所提到的分层架构
关于原书对四层的介绍，我在这里先不原文复述了，我以我的理解（或疑问），分别挑选重点进行介绍：
用户界面层
其实这里有些困惑，我不知道作者是否将前端应用也包含进来。如果没有，那么这里可能就类似我们说的网关，或者路由配置层之类。不过总之，这里并不是领域分析的重点。
应用层
这是一个和领域层的界限相对模糊的一层。在原书中，这一层的描述是这样：
定义软件可以完成的工作....它不包含处理业务规则或知识，只是给下一层中相互协作的领域对象协调任务、委托工作。
“定义软件可以完成的工作”，我们可以理解这是一个应用服务的入口，一个功能单元，一个API，那么，以SpringMVC为例，那么我们开发时入口是什么？自然是@Controller，如果需要事务支持，就在这里加上@Transactional也没问题，千万不要认为事务不加在@Service上就感觉怪怪的，没什么好奇怪的，要摆脱这种思维惯性。
“它不包含处理业务规则或知识”，并非完全“和业务无关”。广义上来说，连一个商业项目的整个架构都是为业务来服务，就算是遵循了“开闭原则”，保证了“扩展性”，依旧是以业务方向做主导。所以，应用层也会涉及业务，但是却非“核心逻辑”。那如何界定？我目前也没有想到一个可以简单描述出来的说法，只是做了一些相对简单粗暴的规定：如果这个功能要求用到一些公共的组件，诸如文件上传下载，EXCEL/WORD等文件解析等明显是工具型做法，一般来说都能放在这一层。
领域层
核心业务逻辑，之后我们讨论的主要内容都在这一层。
基础设施层
持久化读写，公共组件如上面提到的文件下载工具等，还有比如RPC的框架组件等等，都属于此层。这一层可以被上面的任何一层直接调用
所有层允许调用下方层，反之则不然