系統架構的分解，先從業務域進行分解。狹義的業務域具有商業的概念，從這個概念來看，有的系統沒有業務域，當如果寬泛一點來看，業務域就是問題域，問題域總是存在的。
業務域的分解，首先是從系統需求入手，在需求初期可能你就得到的只是一句比較模糊的需求描述，這些需求可能來自於老闆、運營或者用戶（比如下圖的場景）。直接把這句話作爲核心產品功能是不恰當的，合理的做法是先把這個產品的所有問題域列清楚。
列出問題域
問題域，是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能需要解決的問題放入產品框架的範圍，能夠幫助你的產品架構擁有更高的可拓展性，在後續具備迭代和優化空間。
這裏以我做過的一個風控系統需求爲例，問題域集合如下：
詳細的操作步驟：
-
找到收到的需求中，跟產品形態、產品目標相關的語句，去列出“xx的流程會是什麼樣”、“xx該如何達成”之類的問題，直到如果這些問題解決，能夠實現核心需求的方向和業務目標。
-
去逐次尋找這些問題需求被解決的過程中，是否有其他要先解決掉的問題、或者其他跟業務相關的問題能夠被解決。
-
按照層級去羅列所有的問題，並附上自己的初步回答，從而形成一個初步的、自己的產品能夠解決的“問題域”。
確定產品方向
在經過問題域的羅列後，能夠得到一個模糊的產品方向和功能範圍。問題域的環節非常發散，這一步需要回歸基礎，把模糊的需求補充、拓展和翻譯成一個能夠在商業模式和用戶體驗能夠形成閉環的產品需求。
在確定產品方向這個環節的詳細操作步驟：
-
產品用戶：需要明確產品定位的用戶，解決核心用戶的核心需求。
-
核心目標：思考清楚自己產品的核心目標是什麼。如果以一個KPI指標衡量產品的價值，那這個KPI應該是什麼。
-
依賴系統：自己的系統需要與哪些外部系統存在交互和關聯關係，我們的系統在這個大的生態下，是什麼定位。
以風控系統需求爲例，產品方向的描述如下：
繪製業務流程
業務流程是業務架構中比較常見的圖，這一步需要根據產品需求和問題域，按照業務域的流程進行繪製。
業務功能矩陣
通過對業務流程進行分析，根據功能職責，進行垂直分解，識別出業務功能和業務服務，將他們歸類到相應的流程節點中去。將業務流程和業務功能點組合成一張業務功能矩陣。這張矩陣圖是業務架構中爲後續的數據架構、產品架構、技術架構作爲重要的輸入。
功能架構分層
產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的枚舉、功能模塊之間的分界。以業務架構的業務功能矩陣圖作爲輸入，將流程圖轉換成按節點進行分層，節點的功能點存放在同一層中。
在此基礎上將明顯是同一個產品範圍、同一組產品功能的模塊放在同一層級，得到一個基礎的產品框架。
明確功能邊界
一個具備前後臺關係的產品架構圖至少分三層：用戶感知層（在何種場景下通過何種方式觸達用戶）、功能模塊層（通過哪些功能模塊實現產品的核心功能、和哪些外部平臺功能有信息交互）、數據層（產品的數據從哪裏來、產品的數據沉澱到哪裏去）。
在上一步進行簡單分層後，我們已經得到一個初步框架，但是難免會有分層不明確的問題。此時需要按照兩種維度來處理架構圖的層級：不同信息層級的邊界、同一層級內模塊和模塊的邊界。
處理不同信息層級的邊界
架構圖的層級表達其實是信息之間的流轉關係，不同信息層級之間一定是有邏輯關係的。其中用戶感知層和數據層通常化簡爲以（用戶端的功能表達往往邏輯簡單、數據來源問題則不是自己產品的核心功能），而功能模塊則需要按照自己產品的邏輯去將功能模塊層內的主要模塊變成新的層級。
處理同一層級內子模塊的邊界
各層次之間雖有相關，但同一層次內的子模塊之間一定是相互獨立、界限分明的。將解決不同問題的功能拆分成兩個子模塊，做到一個問題只在同一層解決，避免牽一髮而動全身的情況出現。
明確系統間邊界
產品邊界對於開發設計系統架構、業務間的合作模式都非常重要。在架構圖中用不同顏色標識清楚，各個部分所屬系統的邊界。通常屬於自己團隊的部分用亮色標識。像外部系統，如數據層的用暗色標識。
加入信息流
產品架構圖在表達產品的核心功能外，也應該體現信息流動的路徑。當前層級數據的交互形成產品功能，產品功能又產生新的數據，從而推動下一層級的功能運轉起來。
如果當前產品的主要使用角色只有一個，則只需要用箭頭表明模塊間信息流動的方式即可。如果當前產品涉及的角色比較多，則需要用不用顏色的線條將他們和各個模塊之間的信息交互關係表示出來。
最終一種好的產品架構圖，應該具備以下特點：
-
清晰的模塊功能邊界
-
功能經過抽象，做到標準化、互相獨立
-
上下游產品功能邊界清晰，架構分層明確合理，具備迭代優化的能力
延展閱讀
作者介紹
胡斌，菜鳥網絡技術專家，目前負責菜鳥風控系統的建設。曾在淘寶技術部先後負責賣家平臺、商家運營等領域。在大規模分佈式應用、大數據、架構領域有多年的開發和管理經驗。