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