一、序章
一般的工程师接触到的是 应用架构 ,传统的MVC分层架构、事件驱动架构等等。第一次接触业务架构这个概念是在来到商品发布团队之后。商品发布是一个业务属性很重的系统,承载了淘宝、天猫、盒马、魅力惠、汽车、虚拟、SCM自营、苹果、村淘、公益
、教育等诸多业务(业务多的围起来可以绕地球一圈)的商品发布功能。头半年对“业务架构”还是很懵逼的,随着慢慢的熟悉业务,研究框架代码,才对我们的业务架构框架有了清晰的认识。
二、单体应用的痛点
在GPF框架(我们团队的业务架构框架)诞生前,上述的所有业务都在一个单体应用里承载。每新加一个业务,我们的应用工程就会变得更加的臃肿,软件熵变大,代码难以维护,不少类都有几千行以上。不同的业务代码都杂糅在一个类或者一个方法里。
以商品上架时间组件为例,当我们承接教育行业时,我们的代码会做如下的改动(为了方便理解,我把源码改成了伪代码):
/**
* 初始化商品上架时间:
* 1)教育业务发布,开始放入仓库中,且不可修改
* 2)其他业务立即上架
* @return
*/
private int initStartTime(){
if("业务身份"