有赞零售中台建设方法的探索与实践
点击关注“有赞coder”
获取更多技术干货哦～
一、业务背景
1.1 零售SaaS业务架构概览
前台业务主要是面向前端消费者，包含全渠道销售、各业务单元的商品、订单、会员、营销、进销存、智能导购等业务。前台业务的特点是变化快、差异性大；细节性体验、综合性体验；跨平台、多触点。
中台业务承担承上启下、数据打通、业务单元协同的职责。
后台业务主要是面向企业的业务，包括企业内部成熟、稳定的业务，例如生产制造、供应链管理、财务总账等。
1.2 业务复杂度的来源
有赞零售SaaS产品为商家提供一整套的零售解决方案，提供商品管理、进销存管理、门店收银、网店销售、营销推广、客户管理、数据分析等工具，涉及零售经营的方方面面。零售SaaS产品所处复杂的业务需求环境，就像一个黑洞，一不小心就会迷失在其中。所以首先探讨一个问题，零售SaaS业务复杂度究竟来源于哪些方面？下面列举了几个方面：零售企业组织架构复杂；零售业务场景繁多；零售细分行业需求差异化。
1.2.1 零售企业组织架构复杂
1.2.2 零售业务场景繁多
首先看下核算场景，财务中台需要对各类业务场景进行实时核算，这里只列举了销售场景。销售的场景就有很多，比如：门店购物、网店购物、网店下单，门店发货、网店下单，门店自提、门店下单，总仓发货、A店下单B店发货、加盟商下单总部发货等。
结算场景列举了商家和供应商结算、商家和加盟商结算、加盟商和供应商结算。结算又会受经营方式的影响，分为经销结算、代销结算、联营结算。
对账场景列举了应收和收入对账、应收和实收对账、实收和入账额对账、费用对账、资金往来对账。
可以看到光财务领域的场景就非常多，而且核算、结算、对账相互之前也不是独立的，有着错综复杂的关系。如果要为商家提供一整套的零售解决方案，场景多而繁杂是需要面对的巨大挑战。
1.2.3 零售垂直行业需求差异化
生鲜果蔬行业，网店下单门店自提的场景，消费者在网店下单1KG大闸蟹，到门店去自提，服务员按1KG重量去称，但是通常来说，都不会刚刚好1KG，要么多一点，要么少一点。那么少称了，商家需要退钱给消费者；多称了，可能免费送，也可能找消费者补钱。这在其他标品行业是很少见的场景。
蛋糕烘焙行业，为了保证蛋糕的新鲜，消费者网店下单后，大多情况下，是没有成品的，需要基于原材料或半成品加工出成品，然后通过同城配送快速送达到消费者手中。在蛋糕烘焙行业，商品的新鲜程度是非常重要的一个卖点。
母婴亲子行业，通常都是由父母来做消费决策，儿童年龄比较小，没有独立做决策的能力，而且母婴亲子行业是复购率非常高的行业，因此商家非常重视会员的管理与营销。在维护会员信息时，不仅要维护好父母的信息，还要维护好儿童的信息，例如在儿童生日的时候，可以定向推送一些营销活动。
1.3 核心挑战点是什么？
总结一下，零售SaaS产品的核心挑战点究竟是什么？
业务复杂度的挑战：业务问题域本身过于庞大而复杂，业务功能间的相互依赖和影响会导致复杂度指数级地增加，团队无法控制新变化对原有系统的影响。
技术复杂度的挑战：技术复杂度来源于诸如安全、高性能、高并发、高可用性等非功能性需求，随着SaaS产品的用户量不断增长，会为系统设计带来了极大的挑战，然而开发人员容易将业务复杂度的与技术复杂度耦合在一起，导致系统更加错综复杂。
组织上的挑战：由于业务过于复杂，上层的目标又偏概括、抽象，导致业务目标很难拆解落地。当下层发生冲突时，由于业务边界不清晰，很难快速做出有效的决策。
二、如何解决高度复杂的业务问题？
一开始需要做些初期的准备，收集必要的信息，例如：客户是谁，组织结构是怎样的？客户有哪些痛点？客户的业务是如何运作的？
然后要把问题界定清楚，我们需要解决的问题范围是什么？接下来就是结构化的分析、设定阶段性目标、选择工具方法、设计解决方案、实践验证。然后又会有新的需求出现，继续迭代演进。核心围绕2个关键点：问题分治，知识沉淀。
这条链条首先要解决的核心问题是，如何做好结构化分析？因为解决高度复杂的业务问题的关键，是把问题结构化拆解成一个个可解决的小问题，这样我们才能抓住一条主脉络，循序渐进地进行探索和分析，否则只会深陷细节泥潭，迷失在其中。后文会重点讨论一下如何做好结构化分析。
2.1结构化分析——架构类型
结构化分析首先会用到的一个工具是架构类型，分为业务架构、应用架构、数据架构、技术架构。
业务架构包括企业的组织架构、业务域划分、业务能力地图、业务流程等内容。业务架构的核心是定义清楚整个企业的业务是如何运作的，在运作过程中有哪些痛点问题，为不同的问题域划分清晰的边界，梳理出每个问题域的业务需求，并最终提炼出产品需求，为后续系统建设提供清晰明确的指导。
应用架构包括系统划分、应用服务划分、应用间交互等内容。应用架构需要定义整个产品需要建设哪些业务系统，系统间如何集成，系统内是否需要划分应用容器，每个应用容器提供哪些服务能力，哪些服务需要下沉为领域服务，哪些服务直接为前端提供业务服务。
数据架构包括领域模型、物理模型等。数据架构是以业务架构为基础，梳理出企业运作过程中需要记录下来的数据，并通过领域建模方法，提炼出领域模型。除此之外，数据架构还需要考虑数据如何存储，综合考虑数据的一致性、安全性、可靠性、通用性等因素，对物理存储模型进行建模。
技术架构就是传统技术人员比较熟悉的领域，主要是解决各类技术需求，包括部署拓扑、网络拓扑、微服务架构、存储架构等。
4种架构的关系是，最上层是业务架构，应用架构和数据架构一方面支撑业务架构，一方面指导开发人员如何应用IT技术，将业务架构落地。技术架构需要关注具体的技术需求，例如技术框架的选型，以及其他非功能性的需求，例如，高可用、高性能、扩展性、安全、简洁性等。
结构化分析会用到的另一个重要工具是抽象分层。首先说一下为什么要进行抽象分层？
人脑处理信息的能力有限。如果信息量超过了人脑的处理能力，那么人会失去对该事物的理解。零售业务的信息量非常庞大，没有人能够同一时间处理这么庞大的信息量，需要找到一种概括、抽象的方法去理解零售业务。在面对高度复杂的问题时，我们可以通过不断提升抽象层次来解决更为复杂的问题。
沟通协作的需要。团队需要基于统一的设计语言来进行沟通，否则在面的大量复杂问题时，沟通经常会不在一个频道上，出现理解偏差、反复沟通的情况。
让架构设计思路更加清晰有条理。不管是梳理已有业务，还是梳理创新型业务，如果能基于标准化的抽象层次梳理，整个过程将会更加有条理。
有利于领域知识的沉淀和传承。在复杂业务系统的迭代过程中，知识沉淀是尤为重要的，否则业务系统很快就变成一个“大泥球”系统，没有人理得清内部的业务逻辑和业务关系。然而知识沉淀的前提是要有一个知识框架，否则知识没有附着的地方，而标准化的抽象层次就是一个最基础的知识框架。
抽象层次需要结合前文提到的架构类型来梳理，因为不同架构类型的视角不一样，因此抽象层次也不太一样。
业务架构的抽象层次
首先介绍一下业务架构的抽象层次，最顶层是零售企业。
第二层是业务域层次，例如，交易域、财务域、采购域等。
第三层是业务子域层次，例如财务域下细分出存货核算、结算管理、付款管理。这里提到的业务域、业务子域和领域驱动设计（DDD）中的领域、子域概念是对应的，即按照一定规则对庞大的问题域进行细分。
第四层是业务场景/场景分组层次，例如采购结算场景、加盟结算场景、导购结算场景。
最底层是业务能力，可以理解为一个个具体的业务功能，例如，结算单查看、付款申请、代销结算。
应用架构的抽象层次
第二层是系统层次，例如：交易系统、财务中台系统、采购系统等。
第三层是应用容器层次，例如：存货核算应用、结算应用、付款应用。
第四层是组件层次，例如领域服务组件、仓储组件、业务规则组件。
最底层是类。
这里参考了西蒙布朗提出的C4模型。技术架构的抽象层级可以参考应用架构，所以在后文中省略。
数据架构的抽象层次
数据架构的抽象层次不会太多，因为数据模型本身就是高度抽象的、可复用的，本身的抽象级别就很高。
抽象层次之间的关系
三、财务中台架构的落地实践
接下来，结合财务中台架构落地的经验，介绍财务中台是如何循序渐进地进行架构设计工作。
3.1 业务架构分析
首先是业务架构分析，前文中提到业务架构包括企业的组织架构、业务域划分、业务能力地图、业务流程等内容。业务架构的核心是定义清楚整个企业是如何运作的，在运作过程中有哪些痛点问题，为不同的问题域划分清晰的边界，梳理出每个问题域的业务需求，并最终提炼出产品需求，为后续系统建设提供清晰明确的指导。
3.1.1 企业的组织架构
ToB产品和ToC产品有一个显著的区别是，ToB产品面向的客户是企业，ToC产品面向的客户是个人。企业内部有复杂的组织架构，会设立公司、部门、岗位。各个公司、部门、岗位会有不同的职责和权力，三者相互之间会产生错综复杂的关系。所以在获取用户需求时，首先需要梳理清楚企业的组织架构，然后按照组织架构的脉络循序渐进地进行需求调研。在访谈不同层级的用户时，访谈的要点也要有所侧重。前文中1.2.1列举了一个中型规模的零售企业的组织架构，此处不再详细展开。
3.1.2 业务能力图
其次，是业务能力地图，它要表达的是业务域提供那些业务能力。既然是地图，那会有类似国家、省、市、区的概念，前文提到的抽象层次，和地图中国家、省、市、区的概念是一致的。首先是业务域，代表了整个财务中台的问题域，业务域会包含多个业务子域，接着是核心场景，最后是业务能力。通过业务能力地图，我们可以清楚地看到问题域拆解成了哪些子域，每个子域有哪些场景，在场景中，产品需要提供哪些业务能力。这些领域划分、业务能力划分的逻辑能够进一步指导后续应用架构的设计。
3.1.3 业务流程分析
企业级流程：抽象层次是企业，面向人群是零售企业的高层管理，按企业级梳理业务活动，每个业务活动都包含一组流程链。例如一个企业级流程可能包括门店开张、供应商管理、采购、物流配送、销售、售后服务、财务管理等环节。
部门级流程：抽象层次是业务域，面向人群是中层管理，按部门级梳理业务活动，每个业务活动都包含一组子流程。
岗位级流程：抽象层次是业务场景，面向人群是执行人员，列出每个执行场景中详细的操作步骤，类似作业人员的SOP。
梳理业务流程时，需要自顶向下循序渐进地进行，这样才能保证业务流程的梳理工作不重不漏、全面覆盖，进而真实地了解零售企业的业务模式、管理现状，为商家提供直击痛点的解决方案。
3.2 数据架构分析
领域模型设计是非常重要的架构设计工作，因为领域模型是每个业务域和业务子域的核心，后续要实现的各种服务能力，都是围绕领域模型来组织的。领域模型没有设计好，对业务发展的影响是非常长远的，一方面会影响团队对业务的理解，导致系统可维护性越来越差；另一方面如果要建设数据中台，也会让数据中台的建设困难重重。
3.3 应用架构分析
应用架构需要定义整个产品需要建设哪些业务系统，系统间如何集成，系统内是否需要划分应用容器，每个应用容器提供哪些服务能力，哪些服务需要下沉为领域服务，哪些服务直接为前端提供业务服务。
整个应用架构同样是具备层次性的，分为系统层次、容器层次、组件层次、类层次。
3.3.1系统间关系（系统层次）
3.3.2 系统内架构（容器层次）
应用层是提供业务服务，面向场景用例，特点是快速变化。业务服务和业务能力是一一对应的，业务服务的职责就是实现某一种业务能力，因为这一层的服务是直接面向用户，所以这一层变动会非常频繁，为了应对快速变化的外部需求，会通过编排领域服务来实现业务流程的快速适配上线。
领域层提供领域服务，面向领域，特点是共性、稳定。领域层是很厚的一层，它是业务系统的核心所在，包含了领域对象、领域服务以及领域逻辑。用户的需求经常变化，但变化总是有规律的，用户体验、操作习惯、市场环境以及操作流程的变化，往往会导致界面逻辑、应用逻辑变化，但核心领域逻辑不会有太大变化，所以会把共性、稳定的业务逻辑沉淀到领域层，为应用层快速适配业务提供弹药，提高业务需求的响应力。
基础设施层向其他层提供通用的技术服务，例如：分布式通信能力、分布式消息、持久化能力、搜索、任务调度能力等。
3.3.3 应用容器架构（组件层次）
应用层容器内部会分接口层、应用层、防腐层、基础设施层，每层都有各自的职责。应用层容器的职责通常是编排领域服务，实现业务用例。应用层容器通常没有领域模型，因此也不需要访问数据库。
领域层容器比应用层容器多了领域层，这里的领域层是战术级别的领域层，内部包含各种领域模型，领域组件、仓储，关键的业务逻辑、业务规则都主要放在这里。
3.3.4 层次间关系
3.4 技术架构：具体问题具体分析
最后是技术架构，技术架构需要关注具体的技术需求。技术架构要解决的问题就比较杂，主要解决高性能、高可用、可扩展、低成本、安全、业务规模，这几类问题，解决方案也五花八门，由于这块内容非常多，也不是本文的重点，这里只探讨一个问题：如何进行微服务拆分？
3.4.1 如何进行微服务拆分？
微服务拆分的依据是什么？其中一个重要的依据是应用架构中的系统内逻辑架构，需要把哪些代码模块部署到一个微服务中，需要参考逻辑单元是如何划分的，把相关的服务部署在一起，关联性不大的可以分开部署，应用层服务和领域层服务根据重要程度不同，也可以分开部署。另外，还需要考虑是否真的有业务痛点，业务真正遇到了迭代速度慢或高并发等问题，如果不拆分，将对于业务发展带来较大影响。不能为了拆分而拆分，因为每次拆分都会带来运维成本的增加。上图简单示意了一个微服务拆分的案例，只是示意，真实情况会更加复杂一些。
3.5 架构与团队间的关系
四、中台建设的一些思考
4.1 中台是什么？
中台是一套先进的架构理念，通过持续提炼可复用的能力，达到快速响应客户需求的目的。
中台概念来源于阿里的中台战略，但是，中台不能简单地照搬照抄，需要结合企业的业务特点，沉淀一套自身的架构方法论。
4.2 中台建设的基础
4.3 业务中台与架构方法间的关系
4.4 中台思考：几点实践体会
中台建设的基础是建立一套标准的架构方法论，并持续优化。
关注高质量的领域能力建设，避免低质量的重复建设。提高效率、降低成本非常有效的手段。
中台建设是一场持久战，团队共识是关键。
中台建设是手段，不是目的，目的始终是快速响应客户需求，帮助客户成功。不能为了建中台而建中台，如果能助力业务更好发展，那就吸纳进来，如果不行，那中台概念再热门也只能放弃。
五、总结
本文首先介绍了有赞零售的业务背景，讨论零售SaaS业务复杂度的来源，然后引出了3个核心挑战点。接着，探讨了如何解决高度复杂的业务问题，核心是做好结构化分析，重点介绍了2种分析工具，架构类型和抽象分层。然后，结合财务中台架构落地的经验，讲述财务中台是如何循序渐进地进行架构设计工作。最后介绍了中台建设过程中的一些思考。希望通过这篇文章，能为读者在架构设计上提供一些参考价值。
拓展阅读
响应式架构与 RxJava 在有赞零售的实践
有赞零售小票打印图片二值化方案
有赞零售移动端收银商品实践
聊聊UI标准化
有赞零售 App 离线切换技术方案
有赞 Android 编译进阶之路——全量编译提效方案
有赞零售财务中台架构设计与实践