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