浅谈关于业务架构
一、序章 一般的工程师接触到的是 应用架构 ，传统的MVC分层架构、事件驱动架构等等。第一次接触业务架构这个概念是在来到商品发布团队之后。商品发布是一个业务属性很重的系统，承载了淘宝、天猫、盒马、魅力惠、汽车、虚拟、SCM自营、苹果、村淘、公益、教育等诸多业务（业务多的围起来可以绕地球一圈）的商品发布功能。头半年对“业务架构”还是很懵逼的，随着慢慢的熟悉业务，研究框架代码，才对我们的业务架构框架有了清晰的认识。 二、单体应用的痛点 在GPF框架(我们团队的业务架构框架)诞生前，上述的所有业务都在一个单体应用里承载。每新加一个业务，我们的应用工程就会变得更加的臃肿，软件熵变大，代码难以维护，不少类都有几千行以上。不同的业务代码都杂糅在一个类或者一个方法里。 以商品上架时间组件为例，当我们承接教育行业时，我们的代码会做如下的改动（为了方便理解，我把源码改成了伪代码）： 每承接一个新的业务，我们都要添加很多if else式的打补丁代码。严重违反了开闭原则，这种写法是典型的代码坏味道。当承接的业务越来越多时，系统变的越来越庞大。不管是承接新的业务还是对老的业务进行改动，都越来越麻烦。马...
