what：
产品架构的目的：
梳理产品思路，从整体上把握产品的发展方向，把控产品的功能重点（卖点）。它决定了产品必须要实现的功能，以及什么时间必须完成的功能。即决定了产品的发展路径。
产品架构解决的是业务问题，而非功能问题。即该架构只会框定该产品要解决哪些业务问题，取得哪些成果，以及需要哪些数据支撑；而不解决为了完成业务，所需要的具体每一项功能操作。
产品架构图：
是用来抽象表达一款产品服务或者商业模式的可视化工具。
demo图：
how：
1、基本方法“分层”：
最基本的产品层级结构就是三层，即用户层、功能层和数据层。
产品架构是对业务分层设计的过程。
统一用户体验层：
解决的是用户触达的问题，考虑在何种场景下通过何种方式触达用户，最表层的业务体验，也就是我们常说的“用户体验”，包括界面，布局，配色等直观可见的每一个产品页面。
解耦的业务功能层：
“业务功能”的解耦，本质是解决产品的核心功能的设计问题，包括：如何高效的完成业务功能，如何与用户层进行交互，如何与外部系统进行数据通信等一系列复杂的业务处理。
解藕的根本性原因就是：考虑业务的扩展性，也是考虑整个平台的伸缩性。不要把各个功能模块过于紧密的耦合，导致任何些微的改动，都必须大动干戈。
集中的数据处理层：
这一层处理的问题就是，产品的数据从哪里，沉淀到哪里去。实际上，稍微深入一点的问题就是数据如何高效的存储，如何快速的被调用。
分层栗子：
“张三新买的冰箱出现了故障，他找到当时的回执单申报了一次售后服务，要求在周六上午处理完冰箱的故障”。
用户信息：一个方便的界面协助用户申报服务。例如：怎么能让用户在申报服务的时候把资料问题录入正确，有没有办法在用户打开这个界面就直接解决问题，有没有一个FAQ供用户查阅。
业务信息：后台要处理用户的服务请求（申报的售后服务）。例如：要安排一个擅长处理这个故障的工程师上门服务（业务技能要匹配，不能派一个不懂冰箱的工程师处理这个问题），时间是周六（资源要调配，距离太远不合适，时间冲突不合适等）；
数据信息：在处理用户的服务请求时，所需要的一系列动作，以及整个平台的数据和信息是如何进行流转。例如：上次的订单是怎么找到的，这个用户是不是在服务期内，是不是要额外收费，费用是多少。
2、抽象与解藕：
抽象化，就是把具象的业务抽象为一种概念性的词汇。其目的：不仅是为了架构设计的简洁性，更是为了整个平台业务的完整性，并把离散的业务过程场景化。
通过这一层“抽象”以后，就能把用户发起请求，到后续的所有关联性业务，完整的串联起来。从而发现整个过程的不足和缺陷，去通过产品的优化来促进业务的优化。
对用户来说，也只有这种全链路的触点优化，才是真正的用户体验。
业务抽象化的demo：“坐席接到用户王五反馈的问题，安排李四上门服务解决用户的冰箱故障”。
关键信息有：记录问题，安排资源，工程师接受任务，上门服务。则经过抽象后就变为：
受理：坐席把用户反馈的问题记录在案，并形成一个单据
调度：坐席根据用户信息，安排恰当的工程师
接单：工程师接受坐席安排的任务
履约：工程师上门处理用户反馈的问题
这种抽象后的关键节点称之为“业务动作”。“业务动作”即可作为我们构建产品架构的核心信息
