大家好，今天我們來分享業務架構，但是我們並不是以產品經理角度講述一個業務架構是什麼以及如何做？而是以一個技術架構師的角度，講述如何承接業務架構或在沒有業務架構的時候，如何判斷業務變化趨勢而對系統架構提前做出反應。

一、發生背景

研發人有技術架構，產品經理有業務架構（通常是一個人），當一個技術架構師不懂業務架構的時候，就會出現如下對話。

技術工程師小王：“產品經理又改需求，昨天和我說訂單按照庫存狀態拆分，我剛剛上線今天又和我說按照促銷類型類型拆分”

架構師小孫：“業務本來就發展迅速的，那天他還和我說想根據商品體積拆分的，被我擋了回去”。

技術工程師小王：“厲害，還是你有話語權”。

我相信大家經常遇到類似的問題，然而如果技術架構師懂業務架構，就會變成下麵的對話場景。

技術工程師小王：“產品經理又改需求，昨天和我說訂單按照庫存狀態拆分，我剛剛上線今天又和我說按照促銷類型類型拆分，還好，你上次和我說這塊規則是多變的，讓我把不同訂單拆分邏輯，拆分為原子化，我改下配置就搞定，不愧是架構師，你怎麼知道這塊多變？難道會占卜？”

架構師小孫：“哈哈，預知未來本來就是架構師的職責”。

技術工程師小王：“快教教我吧”。

下麵我們就來學習下如何，如何讓技術架構師具有預知未來業務發展的能力。

二、解決方案

技術架構師需要瞭解業務架構的知識，但是又不用像產品經理知道那麼多，例如價值鏈等等概念。他需要知道的如何識別業務發展變化趨勢，並把對應部分的技術架構做好結構化、擴展性。我今天就來介紹一個簡單的方法- MIT知識模型。簡單來說是 1：映射（Mapping） 2 識別（identify） 3 詢問（ask about）

映射（Mapping）：所有的需求可以映射到如下系統化、結構化的語言，電腦程式是在什麼樣的場景（事件）下開始行動，程式需要讀取哪些數據（實體），依據什麼樣的順序（活動）、規則（任務）由誰（組織/角色）執行，執行後會產生哪些數據（實體）。但是針對一個特定的場景來說，順序（活動）、規則（任務）由誰（組織/角色）是更容易多變的。

識別（identify）&詢問（ask about****）：所以我們在和產品經理溝通需求的時候，最主要的是識別順序、規則（組織/角色通常在許可權系統RBAC模型可以配置，可以不用多考慮）。如何快速識別順序和規則呢？

1、 順序：一個場景經過的多個業務活動，這個通常產品經理的業務流程圖會展示，例如商品引入功能，需要經過“洞察”、“選品”、“招商”、“法務”等多個業務流程節點。找到這個順序後，主要問產品2個問題就可以判斷是否多變，“這個順序，是否在不同客戶/渠道/品類等不同端或渠道不同”，“這個順序，是否因為短期上線壓力，妥協只是做了簡化”。通常產品經理在調研的時候會獲得這個信息。如果產品經理不確定，可以讓產品經理在調研下，有個這個信息，在系統架構處理的時候，就可以有多種方式處理擴展性，可以做出多個微服務，或者利用流程引擎工具實現擴展性。

2、規則：通常是（ IF A then B）模式，他通常在在每個順序節點下麵，例如在商品引入的“洞察”的業務活動時候，如果發現有如下話術“如果商品是大家電，需要考慮競對價格因數”，“如果商品是滯銷類型，可以不用參與洞察”等等。如果發現這類術語，基本可以判斷是規則；當然還有些規則比較隱蔽，需要我們來挖掘，例如案例中“訂單按照庫存狀態拆分，我剛剛上線今天又和我說按照促銷類型類型拆分”，這裡其實並沒有那麼明顯的（ IF A then B）模式，但是通常有形容詞的動詞，都有可能變化（例如 按照庫存狀態拆分）。但是如果在挖掘下或仔細思考下，就可以看出出來這個兩個拆分邏輯，一定是有條件或順序的，否則同一個訂單拆分會亂套的。如果在這個時候，我們在追問下產品2個問題，“1、這個規則，是否在特定的條件下才有效，例如客戶/渠道/品類等不同端或渠道、時間段、優先順序順序”。“2、這個規則，在不同客戶/渠道/品類等不同端或渠道，還有可能其他規則“。同樣，如果產品經理不確定，可以讓產品經理在調研下，有個這個信息，在系統架構處理的時候，就可以多種方式處理擴展性，最簡單代碼的可以做策略模式，或利用配置文件、規則引擎dools等實現擴展性。

三、案例分析

通過以上簡單的模型，我們就客戶還原架構師小孫，在和產品經理溝通的需求場景。

產品經理小李：“這次我們要做個業務，訂單履約。這是我的PRD，今天我們一起看下。。。。。。“

架構師小孫：“PRD寫的挺詳細的。通過我這個PRD。我們理解了訂單履約大概要實現的功能，你看我這樣說是否正確：訂單履約功能需求，需要讀取訂單數據，在經過拆分、打標順序，產生多個拆單後訂單，並傳輸給物流系統。通常這些工作，由系統自動處理無需人員干涉。是吧？

產品經理小李：“是的，大的邏輯是這樣的”

架構師小孫：“這裡拆分、打標順序，否在不同客戶/渠道/品類等不同端或渠道不同。是否因為短期上線壓力，妥協只是做了簡化？“

產品經理小李：我調研了4個客戶，3個訂單渠道，以及競品都是經過這個這幾個環節。目前看沒有在新節點的可能性。

架構師小孫：“好的，那我為了成本考慮。我先把流程節點設計為固定，後續你這裡發現有多變的場景及時通知我，另外我看你在拆分環節，提到訂單按照庫存狀態拆分，這裡是所有訂單都按照庫存狀態拆分嗎？”

產品經理小李：“額，我我覺得是“

架構師小孫：“我建議你在調研下，不同客戶/渠道/品類等不同端或渠道下，是否有不同邏輯”，通常在有形容詞的動作，都是可能變化的。

—— 一段時間後

產品經理小李：“嗯是的，客戶A說他們除了庫存、還有運費、禮品卡、商品體積拆分邏輯，這些會按照順序來依次進行“。

架構師小孫：“OK。這塊我設計為可擴展性的”

四、總結陳述

看，架構師有業務預知性或者業務敏感性其實挺簡單的，就是找對位置，多問些問題，就可以為一線研發減少很多工作量。這個能力在很多地方，也可以稱為業務敏感性。所以系統擴展性設計一定離不開業務輸入，但是如何通過幾個簡單的問題，就可以快速找到業務多變的地方，就是我本次分享的MIT模型解決的。大家也可以請根據一個業務場景，按此MIT知識模型分析下業務多變的點。

來源：京東雲開發者社區

作者：京東零售 李春麗（未經授權請勿轉載）