产品架构的搭建通常采用业务架构、应用架构、数据架构、技术架构共同完成。那么，产品的架构设计该怎么做？本文总结了相关思路，希望对你有所帮助。
产品经理的主要职责是根据客户的产品定位，推导出产品需求和功能，然后在技术层面上协助技术完成技术设计工作。
一、产品的来源
产品的源头：
成功经营的公司都会有明确的公司战略，基于公司战略会制定具体的商业模式，通过商业模式从而确定每款产品的定位。
公司高层根据公司战略和商业模式确定产品定位后，产品经理就可以接力产品的设计了。
产品定位和需求：
做产品特别喜欢一句话，“产品经理是发现需求，而不是创建需求”，那么需求从哪里来的哪？
需求的源头有且只有一个 -产品定位。
当产品定位明确后，这款产品要做的事情就明确了，限制条件也明确了，用户是谁也明确了。需求自然就出来了，功能也能拆解出来了。
产品定位为我们指出了使用场景和产品价值：
1、使用场景
- 产品用户：产品给哪些人用？
- 产品用途：产品给这些用户做什么？
- 解决问题：这些用户用这个产品能解决什么问题？
2、产品价值
产品价值：产品能给这些用户带来什么价值？
产品经理做市场调研、用户访谈、竞品分析等工作都是为了回答上面这四个问题。
二、产品架构
产品架构的搭建通常采用业务架构、应用架构、数据架构、技术架构共同完成。
业务架构和应用架构主要描述产品相关的内容。
- 业务架构用来说明该产品的主要业务逻辑，对主要的业务逻辑的支撑是由应用架构和数据架构共同实现的。
- 应用架构用来实现对业务的应用能力的拆分，根据应用能力确定数据架构的内容。
数据架构和技术架构主要描述技术相关的内容。
本文重点介绍业务架构和应用架构。
1. 业务架构（业务层）
业务是实际生产中的活动，业务架构就是对实际生产活动的描述。
业务架构的重点在于将实际生产活动中的问题场景进行拆分，分别梳理出每个场景的需求。
在业务架构中需要描述具体的业务流程，而不是具体的产品功能点。
在设计业务架构时，不需要考虑支撑这些业务场景的功能，这些功能的梳理将在应用系统中涉及。
举例：
比如要求设计一款资源申请和计费系统的系统。通过该系统实现资源的申请，并实现资源的计费及相应的审计工作。
产品定位分析如下：
- 产品给谁用
- 申请者即操作员
- 管理员即处理申请的人。由于系统要求计费，管理员可能细分为：资源管理员、操作审计员、计费管理员
- 用来做什么
- 操作员用来申请资源
- 管理员用来管理资源
实际业务中，产品正常是给大于2个的角色使用，每个角色有需要处理的业务流程，各个角色的工作通过流程整合在一起。
这两个业务场景的详细描述为：
1、申请资源：由普通用户发起，经过审批后获得该资源。在该资源的使用过程中，了解该资源的使用情况，以及该资源的费用情况，同时对资源使用过程中的异常进行有效的处置。
- 由于需要审批需要有流程监测：监测流程的状态和进度
- 获取资源：资源有哪些种类
- 了解资源使用情况：资源的类型不同，管理的方式也比如不同，需要独立的资源管理
- 了解费用情况：需要计费管理，计费管理也有分类，已用计费、年度计费、计费报表等
- 处置异常场景：公告通知（历史公告，当前公告等），告警（各种告警场景梳理）
2、资源配置：由管理员发起，实现对资源的分配和管理。
在资源分配场景中，是将资源按照不同的规则分配给用户。
在资源管理场景中，是实现对资费计费的控制、对资源状态的控制、对资源使用的跟踪，以及告警和公告的发布等内容。
- 由于需要对资源进行分配：各种类型资源的分配规则
- 将资源分配给客户：需要流程管理，流程的设置、发布、回收
- 对资源计费和控制：资源计量
- 需要公告和告警：公告管理、告警管理
业务框架的设计就是将场景的一个个动作提炼为不同的业务功能点。这些功能点按照实际业务场景的不同拆分成不同的功能元素，并按照一定的顺序排序。
常见的排序规则为：
- 时间顺序：如，公告预警
- 流程顺序：如，流程检测
- 结构顺序：如，资源分类、资源检测
按照上述分析可以得到以下业务架构图
2. 应用架构（技术层）
应用架构是对业务架构的偏技术拆解，在应用架构中，通过不同的应用设计实现业务目标，对通用的业务能力进行提炼，通过统一的应用来支撑业务，从而使得业务在应用层面得以实现。
- 在业务中不同的场景逻辑，在应用架构中可能使用相同的应用实现。比如业务员和管理员虽然都有流程管理的相关功能，在应用架构中使用统一的流程管理模块。
- 某些应用场景虽然业务上不重要也不描述，但是在应用架构中是支持的基础。
为了满足业务架构使用场景的要求，应用架构要灵活地将应用与业务进行匹配。
比如，流程检测与流程管理之间是怎么对应的哪？在业务架构中实现的是对四种状态的流程检测，而这四种状态是基于流程实现的。但是在业务场景中是没有流程管理这个场景的，因为流程管理自身并不是一个完整的业务。单独的流程管理无法满足业务需求，满足业务需求的是通过流程来完成的资源申请。在业务架构中不会包括流程管理，但是在业务中需要关注资源的申请进度，是否存在逾期、没有完成审批等情况。因此在业务架构中需要流程检测的业务场景。
应用架构是基于通用性设计来实现业务的支撑，应用架构在设计中隐式的支持业务架构的各种场景，将业务架构场景抽象成应用，实现一套应用支撑多种业务场景的目的。同时对业务场景中通用的部分就行了拓展。
其实就是把业务场景拆开，相同模式的归类到一起。增加了灵活性和适配性。
从面相对象的角度可以理解为：业务架构构建的是对象的行为，应用架构构建的是对象的定义即：类。实际部署时，就是从类开始的对象的实例化。
应用架构的设计需要依靠完整的业务架构，当业务架构能够详细地描述出其所需要的的业务后，应用架构便需要对业务所需要的应用或功能进行梳理和设计。将业务中通用的应用或功能进行提炼，最后形成一幅应用架构图。
3. 数据架构
数据架构基于应用架构的结果对数据进行合理划分，用来明确数据的种类、数据的类型和数据的用途。
数据架构图就是对这些不同类型数据的整理和归纳。
4. 技术架构
技术架构是基于应用架构所需要满足的应用功能，以及数据架构描述的数据类型，选择合适的技术组件来实现整体的技术支撑。
技术架构图是应用架构和数据架构的基础上进行设计。
参考资料：《B端的奇点：产品架构师进阶之路》
本文由 @我是产品张 原创发布于人人都是产品经理。