一、前言
一个新人快速掌握一个新系统业务逻辑的最好的工具是什么,是看代码?是debug?是看uc?是看demo?答案应该都不是,因为看代码和debug一来太耗时,二来系统大了业务逻辑错综复杂,很多业务模块耦合在一起,很难通过debug来理清所有业务,而uc和需求demo又都是零散在confluence不同的地方,并没有一个完整的业务介绍流图,即使有也是很早之前的,随着小需求的不断迭代,业务逻辑早就不是这样了。
所以为了不然代码那么混乱,耦合那么严重,可以采取模块化思想,每个功能模块只对外提供一个service,其他模块不能调用该模块的bo,这个可以通过微服务来实现,但是微服务太重,比如我一个应用有10个模块,总不能搞10个应用吧,基于webx的应用可以通过的子容器实现ioc级别隔离,也可以使用classloader实现cl级别的隔离,这就是模块化。然后如果采用了领域模型,则一个模块内有会有多个域服务。
有了模块化后,那么就要解决如何在小需求不断迭代的情况下维护一个全局的业务文档,这个文档是一个树形结构,树的根是应用名称,树的第二次是应用的模块,第三次则是每个模块中的域服务.....
二、基于注解生成树形业务文档思路
基于上面介绍一个应用划分为若干个模块,每个模块含有若干个域服务,每个域服务内又有可能有若各子域,设计三类注解: