引出这个问题的角度很有趣,是我在总结前端测试分层的实际经验时意识到了业务分层对它的影响。作为前端开发,我不需要像业务分析人员(BA)或者客户一样去分析业务,但是每张故事卡(甚至技术卡),每一行代码却又在消费每一个业务点。虽然敏捷推崇团队里每个成员都要理解需求,但是开发拿到的业务大多都是“分层后的业务”,也就是说是BA分析整理好的业务模块或者业务点(故事卡),并没有涉及太多前期业务分析。然而业务分析和开发过程是强相关的,要去更好的实现技术和测试框架,离不开业务分层。

测试分层

测试金字塔更好的帮助理解测试分层的概念,也对测试分层的实践作出了指导。它将测试分成了三个层次:基于UI的端到端测试、面向Service服务层的中间层测试和Unit单元测试。从用户界面测试到业务模块测试再到单元测试,其实就是面向业务的测试到面向技术的测试的过度。尤其是前端测试会更加直观,对于一个Web应用,大部分业务都体现在用户界面上的业务流。往往从业务流或者功能模块作为切入点,更容易组织代码结构。BDD(行为驱动开发)通过业务通用语言来描述测试用例的方式就是一种体现。

业务分层

业务分层有两个维度:横向分层和纵向分层。

横向业务分层

横向分层很好理解,把复杂的业务分成多个低耦合的业务模块。项目工程(不管是前端项目还是后台项目)按照业务模块的分层来划分目录结构在项目复杂的业务场景里可以有效的组织代码结构。下面是一个基于AngularJS博客系统的前端工程的目录结构。

components/目录下分为不同的业务模块,共享的模块或者辅助模块会放在shared/目录下。这样划分的目录结构一方面更清晰、更灵活、更易扩展,另一个方面,易于测试。它直接对应于测试金字塔中的组件测试,隔离了其他组件对被测组件的影响。

images/
scripts/
----- shared/   // 共用的模块
---------- sidebar/
---------- menu/
----- components/   // 业务模块
---------- blog/
--------------- blogController.js
--------------- blogService.js
--------------- blogView.html
---------- search/
---------- about/
----- app.js
styles/
vendor/
index.html

纵向业务分层

和横向分层相比,纵向的业务分层比较难以抽象。纵向业务分层一般分为三个层次:UI层,业务逻辑层,数据访问层。

纵向业务分层

UI层指的是用户交互层,对于目前流行的前后端分离的Web应用,UI层一般也就是一个前端工程。Restful架构的出现更使得前端界面和后台服务的交互更加清晰,更有层次。不同的前端框架会有不同的抽象层来处理API的请求,即使不采用框架,为了更好的组织代码,通常也会自己抽象出一个Service层。例如AngularJS一般通过Controller中会注入Service来发起请求,调用API接口。一旦抽象出了独立的Service层,就可以不依赖其他层只对Service层进行单独测试。

业务逻辑层和数据访问层属于后台工程。对于一个业务结构清晰的项目,业务逻辑层的业务功能独立,互不引用。这些业务功能体现在后台的Service层(这里的Service层是后台MVC框架中的Service,并不等同于前端AngularJS中的Service层)。然后Service访问数据库获取处理数据。

三层业务结构都和业务的划分息息相关。在项目开始梳理完业务逻辑后,构建数据库的数据结构、列出业务对应的Service接口,对整个项目的模块划分和框架搭建都非常的有帮助。对前后端分离的开发团队,前端人员同样可以根据线框图,列出页面交互设计的API接口列表,同样的可以作为前端模块划分和前端框架的依据。