今天给大家带来的是 2B 领域的一个架构难题，我们最终也没有找到一个较好「解决」方案， 或者说它本来就是一个伪命题。
让我慢慢跟你道来…
软件的划分模式
首先从软件系统的划分模式讲起。软件系统的划分有很多种方式，拆分的目的无非都是：分治、复用、隔离、扩展性、抽象等等。
最为常见的便是分层架构
分层架构将软件系统划分为若干层次，每个层次都是相互独立的，各自负责不同的功能和职责，通过明确的接口和协议进行通信，从而实现系统的可扩展性、可维护性、可测试性、可重用性等特点。
比如一个典型的 Web 系统的“三层架构”：
表示层（Presentation Layer）：负责用户界面、用户交互和用户输入输出等功能，通过 Web 页面或者客户端应用来展示和控制数据的呈现方式。业务逻辑层（Business Logic Layer）：负责系统的业务逻辑处理、数据处理和其他业务规则的实现，为表示层提供数据和业务逻辑的支持。数据访问层（Data Access Layer）：负责数据的存储和访问，为业务逻辑层提供数据访问的接口和实现。
微服务架构
随着系统的复杂化，我们需要将系统拆分为更小的子系统，来解决性能、维护性、扩展性等诸多问题。比如引入了微服务、微前端等解决方案，这个本质上是一种垂直方向的拆分：
甚至我们在应用内部还会进一步拆分, 按照业务聚合度拆分成不同的模块：
这就是分治的魅力吧。
多业态
在 2B 领域，让我们更棘手的是，还要面临多业态问题。
什么是多业态？
让 ChatGPT 来解释一下：多业态是指一个企业或者品牌在不同的业务领域或行业中拥有不同的业态，例如同一个品牌既可以开设餐厅，也可以开设酒店、咖啡店、快餐店、影院等不同的业态。多业态的企业或品牌通过在不同的业态中提供不同的产品和服务，以满足不同消费者的需求和偏好，增加企业的收入和市场份额。
多业态并不是一种结果，而是一种手段。比如在垂直领域耕耘多年的企业，想要扩大创收，就会将触角伸到其他行业，即所谓的跨界。还有就是一些初创企业，就像无头苍蝇一样，将网撒向不同的行业，来摸索出路。
我们就是属于后者。不过也有可能前期策略是在模仿有赞 的嫌疑(毕竟有赞在 18、19 年是当红的 SaaS 炸子鸡)，铺设了很多行业：医药、教育、文旅、零售、地产、汽车…
也就是说在这种「广撒网」的商业策略下, 我们需要在「一套代码」中适配“多业态”：
然而多业态并不是简单的垂直方向的进一步细分，而是多了一个维度。如果说分层是 1D、 垂直划分是 2D、再加上多业态，就是 3D 了！
这些行业多态会横向击穿垂直拆分后的模块壁垒，行业的多样性会渗透到程序的各个角落，开闭原则形同虚设。不管是前端还是后端，这是都是一个非常大的挑战。
现状就是本文标题中讲的，多了一个维度之后，对开发而言是灾难性性，整个项目就是一个大泥球。
所有行业的代码都堆砌在一起，充斥着各种区分行业的 if/else 语句、耦合牵扯、渗透在项目的各个角落… 总之这可能是程序生涯难得一见的代码屎山！
给大家一个直观的体验
垂直的软件拆分有很多方法论，比如微服务、 DDD。而多业态，在软件行业并找不到太多这样的最佳实践。
且不论这是否是战略上的错误。作为技术开发我们只能服从它， 并需求在战术上进行弥补。企业对软件开发的要求并不会因此降低，它还是会要求你的代码要区别「复用性」，要能快速应变各种需求、支持快速迭代…
产品架构
上图是我们团队基本结构，也是产品结构(康威定律)、更体现了我们的项目交付模式。很多非 SasS 化的 2B 公司的应该都是这类模式。
对我们来说更大的挑战在于：下游的项目能尽量复用上游的功能，避免重复工作，并且要求上游的更新能向下传递，甚至不排除下游合并到上游的可能性。
能感受到它的难度了吗？
怎么解决？
战略上的调整
从近几年组织架构上面的调整，可以反映软件架构的战略调整，它定下整个研发体系的基调。另外这些变化，也反映了我们对 2B 行业探索和认知上面的变化：
初创团队就是一个单体团队(左图所示)，接着开始多行业撒网，原本的项目上慢慢堆砌出各种行业的形态(右图所示)。
随着业务发展起来，一些发展较好的行业成立了事业部，专门负责项目的交付。
随着行业的深入，事业部慢慢积累起来了更多行业 Known How，通用的标品已经无法满足需求，事业部开始成立行业标品团队，在行业标准化产品上做更多深入的定制开发；另外事业部内部继续细分专门的交付团队。
