what：
產品架構的目的：
梳理產品思路，從整體上把握產品的發展方向，把控產品的功能重點（賣點）。它決定了產品必須要實現的功能，以及什么時間必須完成的功能。即決定了產品的發展路徑。
產品架構解決的是業務問題，而非功能問題。即該架構只會框定該產品要解決哪些業務問題，取得哪些成果，以及需要哪些數據支撐；而不解決為了完成業務，所需要的具體每一項功能操作。
產品架構圖：
是用來抽象表達一款產品服務或者商業模式的可視化工具。
demo圖：
how：
1、基本方法“分層”：
最基本的產品層級結構就是三層，即用戶層、功能層和數據層。
產品架構是對業務分層設計的過程。
統一用戶體驗層：
解決的是用戶觸達的問題，考慮在何種場景下通過何種方式觸達用戶，最表層的業務體驗，也就是我們常說的“用戶體驗”，包括界面，布局，配色等直觀可見的每一個產品頁面。
解耦的業務功能層：
“業務功能”的解耦，本質是解決產品的核心功能的設計問題，包括：如何高效的完成業務功能，如何與用戶層進行交互，如何與外部系統進行數據通信等一系列復雜的業務處理。
解藕的根本性原因就是：考慮業務的擴展性，也是考慮整個平台的伸縮性。不要把各個功能模塊過於緊密的耦合，導致任何些微的改動，都必須大動干戈。
集中的數據處理層：
這一層處理的問題就是，產品的數據從哪里，沉淀到哪里去。實際上，稍微深入一點的問題就是數據如何高效的存儲，如何快速的被調用。
分層栗子：
“張三新買的冰箱出現了故障，他找到當時的回執單申報了一次售后服務，要求在周六上午處理完冰箱的故障”。
用戶信息：一個方便的界面協助用戶申報服務。例如：怎么能讓用戶在申報服務的時候把資料問題錄入正確，有沒有辦法在用戶打開這個界面就直接解決問題，有沒有一個FAQ供用戶查閱。
業務信息：后台要處理用戶的服務請求（申報的售后服務）。例如：要安排一個擅長處理這個故障的工程師上門服務（業務技能要匹配，不能派一個不懂冰箱的工程師處理這個問題），時間是周六（資源要調配，距離太遠不合適，時間沖突不合適等）；
數據信息：在處理用戶的服務請求時，所需要的一系列動作，以及整個平台的數據和信息是如何進行流轉。例如：上次的訂單是怎么找到的，這個用戶是不是在服務期內，是不是要額外收費，費用是多少。
2、抽象與解藕：
抽象化，就是把具象的業務抽象為一種概念性的詞匯。其目的：不僅是為了架構設計的簡潔性，更是為了整個平台業務的完整性，並把離散的業務過程場景化。
通過這一層“抽象”以后，就能把用戶發起請求，到后續的所有關聯性業務，完整的串聯起來。從而發現整個過程的不足和缺陷，去通過產品的優化來促進業務的優化。
對用戶來說，也只有這種全鏈路的觸點優化，才是真正的用戶體驗。
業務抽象化的demo：“坐席接到用戶王五反饋的問題，安排李四上門服務解決用戶的冰箱故障”。
關鍵信息有：記錄問題，安排資源，工程師接受任務，上門服務。則經過抽象后就變為：
受理：坐席把用戶反饋的問題記錄在案，並形成一個單據
調度：坐席根據用戶信息，安排恰當的工程師
接單：工程師接受坐席安排的任務
履約：工程師上門處理用戶反饋的問題
這種抽象后的關鍵節點稱之為“業務動作”。“業務動作”即可作為我們構建產品架構的核心信息
