阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 mbd.baidu.com/newspage/data/landingsuper 「网络」欢迎转载，保留摘要，谢谢！

• 一、业务架构对产品设计的5个影响
• 二、产品架构
  • 2.1 模块化设计
  • 2.2 渐进式设计

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

当我们去搜索“架构”，可以得到很多的架构图片，比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。

什么是架构，通常大家说架构一般指软件架构，架构是指软件的基础结构，创造这些基础结构的准则，以及对这些结构的描述。在这个定义基础上，我们可以简单理解为架构往往是对事物主体的结构性描述。

产品架构是对产品的一种结构性描述。一般可以包括前端系统、业务管理、运营管理、基础支撑等子产品或子系统，并描述各个子产品或子系统之间的关联关系。

在公司整体战略之下，需要基于公司战略等多种因素设计组织架构，组织架构影响业务架构，业务架构影响产品架构，产品架构影响技术架构。

从这个链条可以看出产品架构基于业务架构。做产品架构前，需要对业务架构有清晰的了解。

一、业务架构对产品设计的5个影响

业务架构是基于组织架构设计的，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织体系、资源分布等内容。

业务架构是一个比较专业的研究课题，技术人员一般对业务架构的关注度相对较低，更重视产品架构、技术架构。这里我们简单示例什么是业务架构，这些架构事实上影响我们的产品架构设计，如下图5-1就是其中一个业务架构设计的框架图。

业务架构对企业的收入模式、支出成本、客户群体、客户关系、需要的资源、关键活动，以及合作伙伴等进行设计说明。

业务架构对产品架构的影响，主要体现在以下几个方面：

1. 系统参与角色

业务架构一般会明确用户范围；营销端的参与人员，比如渠道商或代理商，大客户销售团队等；运营端的参与人员，如售后、客户成功等团队；合作伙伴的参与，如第三方合作平台等。每类角色按需设计对应的使用终端。

2. 系统运营流程

业务架构对运营流程有较明确的定义，如开户、续费、注销、变更、售前售后工单处理、库存入库出库处理、合同流程、发票流程等。这些构成SaaS平台的运营流程，是产品实现商业价值的重要手段，产品环节一般需要有相应的处理。

3. 核心价值

业务架构需要明确SaaS服务对客户带来的价值，这个价值往往需要通过产品端来呈现，业务架构的价值描述，很大程度上就是我们产品建设的侧重点。

4. 周边系统

业务架构中的合作伙伴、资源一定程度上体现出需要与产品交互的其他系统，这些“其他系统”可能是产品需要的一些基础能力（如文字识别、计算能力等）、数据（权限数据、业务数据）、流程（管理流程、运营流程）等 ，而这些能力需要合伙伙伴或者公司的现有资源中提供。这些周边系统会以各种各样的作用支撑着产品的运转。

5. 计费模式

业务架构一般会说明收入和成本模型。收入的处理过程影响运营产品的设计，如公司在线下收款，可以产品只需要控制用户账号的可用状态或有效期，如果是线上收款，就需要设计一套开通、续费的线上支付流程。有些SaaS产品还会涉及到收入和成本费用的摊销，以配合财务工作的处理，也可能需要在产品中完成此类计算。

假如所在公司没有清晰的业务架构，或者部分环节缺失怎么办？如果可以引导，我们尽量引导业务部门完善相关的环节，但有些客观情况是我们无法改变的，我们可以尝试按照现有架构，收集梳理信息，做好整体的结构设计，确保具备可扩充能力，能够满足后续需求，再根据业务各环节成熟度设计产品架构，分阶段去实现。

二、产品架构

SaaS产品架构的设计，可以考虑模块化、渐进式设计。

2.1 模块化设计

所谓模块化是指降低业务间的耦合。低耦合、高内聚是技术架构的重要设计原则，在产品端也非常值得借鉴。

模块式化设计对于系统建模、技术实现、升级迭代、业务推广都有很多帮助。模块化设计也是对最小化场景（MVP）的一种有效支撑。

SaaS产品随着公司的发展，业务范围、功能都会越来越大，而客户可能仅需要部分能力，如果功能间耦合太多，对客户的功能选择会增加限制；销售政策制定起也会受到掣肘，无法灵活组合产品进行销售，对业务推广产生一定影响。

如何做好模块化设计？

模块化设计针对有独立性、可复用的业务或功能进行抽取，包装功能集合构成产品进行推广使用，方便客户根据需要进行产品组合，模块化设计在传统软件中也非常重要。

（1）归类与抽象

需要对相似的功能或者场景进行归类然后抽象出来进行设计。在软件设计领域，越是底层的东西越容易复用，越是偏向应用端的东西，越难以复用。比如构成一套软件服务，可以有服务器硬件、应用服务中间件（比如数据库等）、各种微服务、业务流程、外部入口等，这套软件架构中，服务器硬件是处于架构底层，比较基础且通用性很强；应用入口处于架构高层级，形式相对灵活，复用性较低。在产品端也是同理，基础信息如人员、机构等属于基础信息，同一组织在不同系统中的结构大体一样，复用性强，其次是各类业务流程，再其次是业务表单。

我们要做的产品模块化设计，是针对不同用户的需求，将完成某项业务的场景进行分析、归类、抽象，抽取共性部分，做成可实现多种组合的产品形态。

（2）数据接口

系统一般由逻辑（算法）和信息两部分构成，信息又分为内容和数据；逻辑是构建软件功能的骨架，内容和数据是血肉，其中以数据尤为重要。

假如要实现软件模块化且模块之间相互独立，必须要先抛弃逻辑（实现方法），因为有逻辑就代表这两个模块谁也离不开谁，就不能称之为独立。

如果这两个模块必须要关联在一起，但又不允许它们在逻辑上互相干涉，那么最好的办法就是为它们内部包含的数据进行抽象化，形成标准化接口，以数据调用的形式实现两个模块间的互相协作。

模块化的一个特征是复用，在产品设计上复用意味着需要多种场景的结合，如果只有一个场景，就不是复用，在多个场景都需要使用的情况下，会有数据交互的需要，模块化设计就是要把共性的东西抽取出来后，提供标准接口，进行数据交互，这个共性的东西，可以是字段，也可以是规则。

大家通常理解的SDK，也是模块化设计的一种体现。模块化的产品可以是一个界面、也可以是一个功能，还可以是一个子系统。

2.2 渐进式设计

SaaS产品是逐步迭代的，产品设计也不是一蹴而就的，需要有一个不断前进的过程，渐进式设计非常契合SaaS产品。比如我们公司的产品，有企业客户、集团客户、代理商、平台运营人员、售后人员等参与，在设计系统的过程中，并不是一上来就把所有的工作全部做完， 这样周期太长，也不利于快速验证产品和市场的匹配，所以产品架构自然而然也变成了一种渐进的设计过程。

渐进式设计需要尽量考虑未来产品的全局，以满足后续产品扩展需要。

以我曾经做过的一个产品举例，产品的用户可以分为三大类，关系如下图：

在产品架构的搭建过程中，我们在清楚有这些基础结构以后，按照优先级顺序，逐步发展产品。如图：

产品架构示例图

首先搭建了企业版产品和简单的运营管理系统，让用户能够使用起来。后来随着代理商力量的不断计入，需要为代理商设计一套管理系统，代理商系统需要依赖于公司运营管理系统（公司运营早期就已经有了代理商加入，运营管理平台只有最简单的代理商管理功能，能够标记客户所属代理商，但并没有去开发一套代理商管理系统，只是预留了扩展能力）。

随着平台的发展，用户群体不断扩大，集团客户也在不断增加，公司又基于企业版产品开发了集团版产品，满足集团企业客户的需要。

整个代理商管理系统和公司运营管理系统也跟随迭代，从最初的企业注册审核，到用户工单管理、结算续费管理、再到增加集团版的开通管理流程及结算流程，历时用了几年时间。产品整体架构经历了多个版本的迭代，才逐步变成现在的体系，并且还在持续完善中。

产品架构的渐进式设计和最小化可用产品（MVP）并不是一回事，产品架构渐进式设计是为了产品稳步推进并可扩展，先集中精力解决当前的重要需求和问题，所积累的产品成果，会成为将来产品发展的基础，而不是MVP中表示的每一个过程都可能要重构。

MVP有一个非常生动的例子，用户需求是一辆车，那么车的MVP及产品演进过程应该如下图5-5的第二部分所示：

产品架构的渐进式设计和产品的MVP有什么关系，其实是两个维度的事情，产品架构渐进式设计是对现在业务的快速响应，以及对未来业务扩张的支撑。

MVP是在产品迭代过程中，在不同的阶段，可能需要进行重构，上图的例子，在一些产品论坛上都有阐述，这对MVP的解释是很准确的，最小化可行产品需要做到每次迭代都是完整可用的，可用场景闭环是MVP的核心指标，这是产品从0到1的一种有效验证方式，但我认为这种重构并不一定是必须的.

很多软件产品在迭代的过程中，都是在原有基础上的扩展，实际上产品架构具备弹性和扩展性，这是一名优秀产品经理需要具备的能力，毕竟任何历史投入都是有成本的，优秀的设计应该是在原有基础上的扩展，而不是推倒重来。

B端产品在发展过程中，也比较注重产品和服务的结合，这个服务并不是指产品即服务，而是在早期产品不够完善的情况下，部分环节通过线下服务来补充，这也是SaaS产品发展的一种形式。

产品架构大体能够说清楚了系统间的关系，但对于具体的产品流程，产品架构图是无法表达清楚的，还需要辅助系统流程图进行说明。