基于领域分析设计的架构规范领域分析基础.docxVIP

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