产品架构设计：从业务到技术的递进

产品经理的主要职责是根据客户的产品定位，推导出产品需求和功能，然后在技术层面上协助技术完成技术设计工作。

一、产品的来源

产品的源头：

成功经营的公司都会有明确的公司战略，基于公司战略会制定具体的商业模式，通过商业模式从而确定每款产品的定位。

公司高层根据公司战略和商业模式确定产品定位后，产品经理就可以接力产品的设计了。

产品定位和需求：

做产品特别喜欢一句话，“产品经理是发现需求，而不是创建需求”，那么需求从哪里来的哪？

需求的源头有且只有一个 -产品定位。

当产品定位明确后，这款产品要做的事情就明确了，限制条件也明确了，用户是谁也明确了。需求自然就出来了，功能也能拆解出来了。

产品定位为我们指出了使用场景和产品价值：

1、使用场景

• 产品用户：产品给哪些人用？
• 产品用途：产品给这些用户做什么？
• 解决问题：这些用户用这个产品能解决什么问题？

2、产品价值

产品价值：产品能给这些用户带来什么价值？

产品经理做市场调研、用户访谈、竞品分析等工作都是为了回答上面这四个问题。

二、产品架构

产品架构的搭建通常采用业务架构、应用架构、数据架构、技术架构共同完成。

业务架构和应用架构主要描述产品相关的内容。

• 业务架构用来说明该产品的主要业务逻辑，对主要的业务逻辑的支撑是由应用架构和数据架构共同实现的。
• 应用架构用来实现对业务的应用能力的拆分，根据应用能力确定数据架构的内容。

数据架构和技术架构主要描述技术相关的内容。

本文重点介绍业务架构和应用架构。

1. 业务架构（业务层）

业务是实际生产中的活动，业务架构就是对实际生产活动的描述。

业务架构的重点在于将实际生产活动中的问题场景进行拆分，分别梳理出每个场景的需求。

在业务架构中需要描述具体的业务流程，而不是具体的产品功能点。

在设计业务架构时，不需要考虑支撑这些业务场景的功能，这些功能的梳理将在应用系统中涉及。

举例：

比如要求设计一款资源申请和计费系统的系统。通过该系统实现资源的申请，并实现资源的计费及相应的审计工作。

产品定位分析如下：

1. 产品给谁用

• 申请者即操作员
• 管理员即处理申请的人。由于系统要求计费，管理员可能细分为：资源管理员、操作审计员、计费管理员

2. 用来做什么

1. 操作员用来申请资源

2. 管理员用来管理资源

实际业务中，产品正常是给大于2个的角色使用，每个角色有需要处理的业务流程，各个角色的工作通过流程整合在一起。

这两个业务场景的详细描述为：

1、申请资源：由普通用户发起，经过审批后获得该资源。在该资源的使用过程中，了解该资源的使用情况，以及该资源的费用情况，同时对资源使用过程中的异常进行有效的处置。

• 由于需要审批需要有流程监测：监测流程的状态和进度
• 获取资源：资源有哪些种类
• 了解资源使用情况：资源的类型不同，管理的方式也比如不同，需要独立的资源管理
• 了解费用情况：需要计费管理，计费管理也有分类，已用计费、年度计费、计费报表等
• 处置异常场景：公告通知（历史公告，当前公告等），告警（各种告警场景梳理）

2、资源配置：由管理员发起，实现对资源的分配和管理。

在资源分配场景中，是将资源按照不同的规则分配给用户。

在资源管理场景中，是实现对资费计费的控制、对资源状态的控制、对资源使用的跟踪，以及告警和公告的发布等内容。

• 由于需要对资源进行分配：各种类型资源的分配规则
• 将资源分配给客户：需要流程管理，流程的设置、发布、回收
• 对资源计费和控制：资源计量
• 需要公告和告警：公告管理、告警管理

业务框架的设计就是将场景的一个个动作提炼为不同的业务功能点。这些功能点按照实际业务场景的不同拆分成不同的功能元素，并按照一定的顺序排序。

常见的排序规则为：

1. 时间顺序：如，公告预警
2. 流程顺序：如，流程检测
3. 结构顺序：如，资源分类、资源检测

按照上述分析可以得到以下业务架构图

2. 应用架构（技术层）

应用架构是对业务架构的偏技术拆解，在应用架构中，通过不同的应用设计实现业务目标，对通用的业务能力进行提炼，通过统一的应用来支撑业务，从而使得业务在应用层面得以实现。

1. 在业务中不同的场景逻辑，在应用架构中可能使用相同的应用实现。比如业务员和管理员虽然都有流程管理的相关功能，在应用架构中使用统一的流程管理模块。

2. 某些应用场景虽然业务上不重要也不描述，但是在应用架构中是支持的基础。

为了满足业务架构使用场景的要求，应用架构要灵活地将应用与业务进行匹配。

比如，流程检测与流程管理之间是怎么对应的哪？在业务架构中实现的是对四种状态的流程检测，而这四种状态是基于流程实现的。但是在业务场景中是没有流程管理这个场景的，因为流程管理自身并不是一个完整的业务。单独的流程管理无法满足业务需求，满足业务需求的是通过流程来完成的资源申请。在业务架构中不会包括流程管理，但是在业务中需要关注资源的申请进度，是否存在逾期、没有完成审批等情况。因此在业务架构中需要流程检测的业务场景。

应用架构是基于通用性设计来实现业务的支撑，应用架构在设计中隐式的支持业务架构的各种场景，将业务架构场景抽象成应用，实现一套应用支撑多种业务场景的目的。同时对业务场景中通用的部分就行了拓展。

其实就是把业务场景拆开，相同模式的归类到一起。增加了灵活性和适配性。

从面相对象的角度可以理解为：业务架构构建的是对象的行为，应用架构构建的是对象的定义即：类。实际部署时，就是从类开始的对象的实例化。

应用架构的设计需要依靠完整的业务架构，当业务架构能够详细地描述出其所需要的的业务后，应用架构便需要对业务所需要的应用或功能进行梳理和设计。将业务中通用的应用或功能进行提炼，最后形成一幅应用架构图。

3. 数据架构

数据架构基于应用架构的结果对数据进行合理划分，用来明确数据的种类、数据的类型和数据的用途。

数据架构图就是对这些不同类型数据的整理和归纳。

4. 技术架构

技术架构是基于应用架构所需要满足的应用功能，以及数据架构描述的数据类型，选择合适的技术组件来实现整体的技术支撑。

技术架构图是应用架构和数据架构的基础上进行设计。

参考资料：《B端的奇点：产品架构师进阶之路》

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！