写在前面
正交软件架构是一种很常见的架构模式，往往由分层架构演化而来。俗话说“不识庐山真面目，只缘身在此山中”。虽然我们整天吐槽着正交架构的各种问题，却没有能够对其有一个完整的认识。本文将结合业界实践，从架构演化的视角剖析这一架构模式，探索正交架构的前世今生，全面介绍这一架构的结构和优势，分析实践中的缺陷并探讨解决方案。
关于架构的基本认识
软件系统架构（简称架构）关注软件系统的结构和全生命周期内的演化。软件系统的结构是指构成软件系统的基本元素和元素间的相互关系；演化过程包括软件系统为何创建、为何下线、如何适应外界环境的变化、以及约束软件行为和表现的一系列原则。任何一个软件系统都有其架构，不存在没有架构的软件系统，只有不能把架构说明白的架构师。
架构图是架构师为了向系统特定的利益相关者展示系统架构设计而绘制的系统某一方面的结构关系图。常见的架构图有：管道架构模式中常用的数据流图、面向对象架构模式中常用的类图、企业应用开发中常用的实体关系图、描述系统如何部署的部署图等等。架构图不等同于架构。在实践中，受限于时间和资源约束，我们不能也没必要将系统架构的方方面面都完整而全面地描述清楚；我们更多地是在描述利益者关注的部分和对系统架构决策有重大影响的部分。我们无法也没必要通过一张架构图呈现出系统全部的架构细节。因为，我们没有无穷无尽的时间去描述特定系统的架构细节；将多个架构图合并会造成信息过载，架构图的阅读者难以理解、吸收和消化。
复杂系统往往是多种架构模式组合使用，我们在系统的某一视角上选用一种架构模式时，并不意味着对其他架构模式的弃用。例如：目前主导系统间交互的架构模式主要有面向服务的架构、微服务、Service Mesh，当我们选择他们的时候并不意味着我们单个系统不能选用面向对象的架构模式；当我们选用面向对象的架构模式时，也不意味着系统的网络部署不能选择层次架构模式。我们在讨论某一种架构模式时，往往是指系统的某一方面采用了这种架构模式。
企业信息系统是为支持企业运作而开发的具有数据输入、传输、处理和输出等基本功能的计算机系统。企业信息系统往往由多个部分组成，我们可以按照管理对象的不同将这些子系统分为三类：管理计算机资源的系统、管理数据的系统、对其他系统进行集成的系统；其中管理数据的系统又可以细分为管理事务的系统和分析数据的系统。“管理计算机资源的系统”就是我们俗称的能力系统，典型的能力系统包括系统软件如数据库软件、中间件软件如ESB。“管理事务的系统”就是我们俗称的对象系统，系统中的主要、关键、核心数据就是我们俗称的“对象”。“ 对其他系统进行集成的系统”就是我们俗称的应用系统，他们并不直接管理、存储业务数据，而是通过调用其他系统的服务进行整合集成。也可以从软件的核心价值进行分类：以“数据”为核心价值的就是对象系统，如管理供应链中交互信息的订单、产品、库存系统；以“系统集成”为核心价值的就是应用系统，如各种大前端应用系统；以“软件”为核心价值的就是能力系统，如数据库软件系统、中间件软件系统。如图1所示，企业信息系统在一种视角下呈现出层次架构模式。现实中的系统既有专门负责单一职责的独立系统，如云平台管理系统；也有同时承担多种职责的系统，如订单系统即管理订单数据和处理订单的事务，也会对其他系统进行集成。这几种类型的系统中，管理计算机资源的系统”是最稳定的，受业务变动影响最小；“ 对其他系统进行集成的系统”是变化最频繁的，受业务变动影响最大；“管理事务的系统”中，数据逻辑是比较稳定的也就是数据架构部分稳定性较高，事务逻辑的变化则比较频繁也就是应用架构部分的变化比较频繁。
图1
“管理事务的系统”往往伴随企业业务变化而演化，本文将围绕“管理事务的系统”应用架构演化过程进行讨论。
层次架构的演化过程
企业的销售渠道中有买卖中间商和代理中间商两种角色。买卖中间商通过先买后卖的方式流通商品，能够赚取批零差价；而代理中间商仅仅是消费者和商品实际提供者之间的沟通桥梁，甚至仅仅为商品实际提供者介绍高质量客户，赚取的是返佣。买卖中间商中，直接向消费者销售商品的也叫零售商。
No.1
市场探索期
初创企业往往没有明确的目标市场，以“代理中间商”的形式试水就是一种低成本的“试错”方法。对一家在线销售代理中间商来说，最核心的只有客户、商品、订单、供应商四个对象（如图2所示）。在网络平台上展示商品，客户选择商品后生成订单，将客户推荐给供应商，在客户与供应商签约后获得返佣，使用订单对象管理客户的签约、返佣的结算等。此时代理商最核心的工作就是：向客户推荐商品，向供应商推荐客户，为客户与供应商牵线搭桥。
图2
对于代理中间商来说，其最有价值的资产就是客户资源，通过将客户推荐给上游供应商获取盈利。但本身这种经营模式却无法维持客户资源，当客户被推荐给供应商后，客户就变成了供应商的资源，同时自身就失去了这一资源。要如何应对这一问题呢？一种思路是做大自身做成交易平台，扩充商品种类，做双边市场，消费者和供应商都必须依赖平台才能完成交易；另一种思路是深耕目标市场，聚焦某一类商品，向产业链上游发展，以质量、效率制胜，战胜行业竞争者。本文主要围绕后一种思路讨论。
No.2
目标市场确定期
目标市场确定后，要想从代理中间商转变为买卖中间商，一种很自然的方法就是：客户与中间商签约，中间商收到货款后实时向上游供应商采购。对于实物商品来说，客户签约后由供应商直接发货；对于服务商品来说，则是客户签约后直接由供应商提供服务。中间商在整个环节中，仅需确保与客户的买卖合同、与供应商的采购合同有效就行，而无需考虑后续产品的交付环节，也不会发生一般意义上后的采购、发货、收货、入库动作。也就是说，在这样一种模式下，“采购”只会涉及资金流、信息流，而不会涉及到物流（如图3所示）。
在这样的一个场景中，涉及到消费者、买卖中间商（也称零售商）、供应商三方的库存和销售信息同步（如图4所示），其中协调信息同步的就是买卖中间商，就有了我们俗知的“询占确”概念。由于是一单一采，所以此时的采购管理耦合在订单管理中。
图3
图4
销售旺季时市场上的资源非常紧俏，客户晚一分钟付款供应商的资源都有可能被别的零售商抢走。如果我们能够预先锁定一部分紧俏资源，销售旺季时就能更加轻松的赢得订单，减少资源不足的可能性，提升销售效率。
No.3
行业竞争期
预先采购为库存能够加强企业的竞争优势。对于服务型商品来说，零售商预先向供应商锁定一定数量的资源，只要不超过该数量，都可以先销售再向供应商提供客户资料（如图6所示）；余数不足时，则需要向供应商实时采购。此时的库存仅仅对余数进行管理，故耦合在商品属性中。
图5
图6
随着企业的逐步发展，企业所采购的单元不再是所销售的单元，两种单元之间存在组合关系。作为商品属性的库存系统不再适应企业发展的需要。
No.4
行业深耕时期
企业不能仅仅是商品流通的管道，直接采购原材料并进行打包售卖能够显著的降低成本，进而降低商品售价提高市场竞争力。我们将直接采购进来的单元称作“资源”，库存管理的核心对象是资源。商品管理其与资源的组合关系（如图7所示）。
图7
至此，我们看到了非常典型的分层架构（如图8所示）。分层架构的系统内部组织成层次结构，其优势有：
（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
（2）支持功能增强，因为每一层至多和相邻的上下层交互，所以功能的改变最多影响相邻的上下层；
（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样就可以定义一组标准的接口，而允许各种不同的实现方法。
No.1
市场细分期
随着企业的发展，客户的种类也越来越多，不再仅仅是个人消费者，还有团体消费者和企业消费者（如图9所示）。不同的消费者服务部门均有自己的客户管理、销售管理、库存管理、采购管理和供应商管理系统。
图9所示的是一个典型的正交软件架构。正交软件架构由组织层和线索的构件构成。层是由一组具有相同抽象级别的构件构成；线索是子系统的特例，它是由完成不同层次功能的构件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的。可以看出，正交软件架构是一种以垂直线索构件族为基础的层次化结构，其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的构件构成。各线索的相同层次的构件具有相同的抽象级别。
No.2
横向发展期
除了客户种类，商品种类也会导致系统的横向扩充（如图10所示）。例如，面向个人消费者的产品中，有打包产品、单项产品、特卖产品等。
图10所示的是一个大型的和复杂的软件系统，其子线索（一级子线索）划分为更低一级的子线索（二级子线索），形成了多级正交结构。
正交软件架构具有以下优点：
（1）结构清晰，易于理解。正交软件架构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。
（2）易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的构件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需相应的增删线索构件族，而不影响整个正交架构，因此能方便地实现结构调整。
（3）可移植性强，重用粒度大。因为正交结构可以被一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现架构级的重用。
应用正交架构所面临的挑战
虽然正交架构的结构非常清晰、易于理解，但实践中我们发现：线索之间无法做到没有关联或很少关联（如图11所示）。破坏这一条件的原因是：不同业务线之间的资源、库存、采购可以共享，而且也应当共建共享。
如图11上“内部采购”所示，在“进销存”逻辑方面，一个业务线可以向另一个业务线发起采购，企业需要将自身作为自己的供应商和分销商，同时在财务处理方面要扣除这部分虚增的业绩。
如图11上“父子订单”所示，某些商品在促销、甩卖时，为了简化客户的操作，独立建设了订单处理系统；与此同时，库存采购流程不变。这种时候，将一个线索下的订单作为另一个线索下的子订单，就大大降低了系统开发成本。
实践中“库存管理层”没有能够隔开“销售管理层”和“采购管理层”，只有库存商品才由“库存”处理，非库存产品则由“订单”与“采购”直接对接。
实践中的另一个问题则是“商品”与“资源”之间、“资源”与“资源”之间的关系暂未明朗。
还有一种场景则是“集中采购”，很明显系统上各个线索各自为政，不存在集中采购的可能。
在上述多种原因的共同促进下，我们还能够观察到循环依赖的现象：A、B是两个独立的业务线，都通过“内部采购”的形式共享库存，A通过采购询问B，B接收到请求后再通过采购询问A，因此形成循环。
除了系统层面的问题外，开发团队也是按业务条线管理，相互之间缺少沟通，形成“烟囱式架构”，无法发挥“可移植性强，重用粒度大”的优势。
建设“大库存”，迎接挑战
认识到当前存在的客观问题和不优雅的解决方案之后，一个很自然的想法就是建设“大库存”，也就是将“库存管理层”做实。
“大库存”的“大”字直接体现在：统一管理所有东西的库存，各个订单系统直接与统一的库存系统对接，不再需要相互引用、内部采购。库存统一后，“集中采购”能够在系统上落地，采购系统和供应商管理系统就自然统一了。
“库存管理层”的核心职责是建设“库存模型”。库存模型包括补充（输入）、存储和需求（输出）三部分，一般需要回答：何时补充、补充多少才能使总库存费用最少。总库存费用一般包括存储费、订货费、缺货费三个部分。图4描述的近似瞬时进货、允许缺货模型；图6描述的则近似逐渐进货、允许缺货模型。只有建立好“库存模型”，“库存管理层”才能隔离开“销售管理层”和“采购管理层”，降低销售与采购的耦合。
“库存系统”除了常见的入库、出库、批次管理外，还要支持库存的组装与拆分。“物料管理”就是为这一功能提供支持。传统上，一切物质的东西都可以成为物料，在服务业场景下，则应当延升为：一切物质的东西或一切向客户提供的服务内容都可以成为“物料”。具体的“物料”在组织内部必须达成共识，同一“物料”在物料系统中仅能存在一个。“物料”的信息包括：技术资料信息、用于库存管理的信息、用于采购管理的信息、用于销售管理的信息、用于财务管理的信息。服务型“商品”是一套解决方案的抽象，会存在多种具体的“服务项目组合”；同一套“服务项目组合”也能针对不同的客户包装成不同的“商品”销售。因此，一个“商品”可以对应多个“物料”，一个“物料”也可以对应多个“商品”。但一个订单只应当有一个确定的“物料”。“物料”除了最小不可拆分的单元外，还可以是各种“单元”的组合。表示“物料”组成结构的“物料清单”（即产品结构树）是实现库存组装与拆分的基础。
写在最后
本文从架构演化的视角剖析了正交架构的特点以及实践中所遇到的问题，众人拾柴火焰高，问题的最终解决还需要大家齐心合力共同努力。
期待我们演化出新的架构模型！
=>更多文章请参考：《中国互联网业务研发体系架构指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：
转载：https://blog.csdn.net/Ture010Love/article/details/104272695