企業商務模型的主要內容包括主營業務、商務模式、商務主體、競品分析、組織架構、商務運作模型和業務流程等。
主營業務即公司做什麼業務，商務模式即公司怎麼賺錢，商務主體即哪幾個人在一起做這門生意，競品分析即瞭解競爭對手的情況，組織架構即公司部[ ]是怎麼劃分的。在組織架構圖中標出人數，根據系統與業務之間的對應關係，可以瞭解系統中哪些模塊使用的頻率高，以及業務與其對應模塊的複雜度。商務運作模型即公司是如何運作的，售前做計劃，找供應商把東西買進來後，經過服務和結算，再賣給經銷商和採購商，使我們獲得利潤，售後進行大數據分析後又指導我們的售前，整個過程形成良性循環。可以把一家公司想象成一臺機器， 輸入的是錢，轉一轉後，又能夠生出更多的錢出來。商務運作模型如下圖所示。
最後是業務流程和附檔資料。業務流程包括預訂流程、訂單處理流程、產品供應流程、財務結算流程、賬戶管理流程。企業商務模型的建立，指導整個應用系統模型的建立，它是整個應用系統建設的基礎和前提，畢竟應用系統是爲業務服務的。
架構現狀的內容主要包括功能架構、應用架構、數據設計和物理架構。
功能架構
採購商的功能如下圖所示。
功能架構主要包括功能、角色和權限三部分。
功能是企業服務，用戶使用的每一個功能就是企業的每一個服務。
角色是用戶操作的歸類，
功能與角色的對應關係即權限。
瞭解系統架構的現狀，從功能架構開始。
應用架構
應用就是處理器，應用架構的內容包括現有架構圖、Web應用現狀、作業小應用(Job)現狀和接口架構。其中，接口是應用層面的關鍵，它是一個程序與另外一個程序交互的部分。
業務邏輯被多少個應用調用，就需要被重複開發多少次，一旦改了一個地方，就要同時改多個地方，導致系統開發效率非常低下。各業務邏輯如預訂邏輯，雖然被多個應用調用，但它與應用是沒有關係的，業務邏輯可以獨立存在，也可以寄宿於多個應用。業務邏輯是一個業務操作的抽象，而業務應用與業務部門]共同完成了業務操作。
數據設計
100多個數據庫，一萬多張表，能否使用一張E-R圖來表示呢？可以的。數據設計依賴於企業的數據，而不是數據庫的設計，將企業數據適當歸類，會直接導致數據設計，最終畫出E-R圖，數據設計完成後，數據庫設計就自然而然出來了。超越庫、超越表去看這張E-R圖，可以看出它包括產品、訂單、結算、用戶、基礎設施這五類數據。低層的E-R圖可以變，但是高層的E_R圖一般不會變化，因爲它是根據業務模型而定的，業務模型穩定，高層E-R圖也是穩定的。數據庫只要早期設計得好，是可以做到易伸縮、易拆分的。下圖從內往外看，一個框既可以是一個庫， 也可以是一個模塊，還可以是一個表。在業務發展的早期它可以是一個庫，裏面有5個模塊，中期可以分爲5個庫，後期以更低級別可以分爲更多的庫，這與業務階段及系統複雜度相關。在數據的設計完成後，數據庫的設計也就很容易進行規劃和調整。
以上是數據庫、數據表之間的靜態關係，接下來我們介紹數據的流轉狀態，即狀態圖。通過數據狀態圖去了解現有數據的流轉變遷，從等待支付到支付成功，中間有一個支付行爲，通過這個支付行爲把數據狀態變更爲支付成功，否則繼續等待，直到超時關閉訂單。這個支付行爲可以做成一個微服務，然後由不同的應用去調用。
物理架構
物理架構的內容主要包括IDC機房、機房之間的訪問關係、機房內服務器物理部署圖、機房與業務分佈、網站架構、數據庫架構、集羣清單和域名清單。將這些內容以列表和圖形方式整理出來，就很容易瞭解和發現問題，只有發現問題才能解決問題，特別是在全局體系架構方面，這也是表和圖的價值所在。當時這家公司共有5個地區、8個機房，雖然只有200 多臺服務器，但分佈很散，導致物理結構複雜，通信也很複雜。技改前故障不斷，主要的原因就是物理架構不合理，運維要佔60% ~ 70%的責任，當時卻把責任歸咎爲應用架構，這是錯誤的方向。物理架構不合理，應用架構是很難合理的，因爲物理架構是我們的基礎設施，位於底層，下層爲上層服務，運維要爲應用服務，應用要爲業務服務，業務要爲客戶服務。
領域模型
領域模型關注概念、關注職責、關注邊界、關注交互，只有先確定職責和邊界，交互纔會很清晰。領域模型是針對現有問題域提出一個系統解決方案，然後在圖表上建立完整的模型，如同用AutoCAD畫的施工圖紙一樣。領域模型屬於概要設計階段，對於單個應用架構設計，首先需要了解業務和功能需求、用例圖、用例活動圖，然後纔是領域模型。業務流程圖是對業務操作的抽象，領域圖是對業務邏輯代碼的抽象。
預訂模型如下圖所示。
建立領域詞彙是建立領域模型的第一步，它能統一詞彙、 明確概念，以減少一詞多義、一義多詞的情況。概念一旦確定，再擴展屬性和行爲，然後把它當作一個單元與其他事物構建在一起，就很容易形成模型，領域模型與企業商務模型中的業務流程圖有對應關係。領域模型在實現時可大可小，在業務的早期，系統比較小的情況下，它有可能是一個類。當系統做大了以後，它可能是一個DLL庫。再做得更大一點的時候，它可能是一個服務，給不同的應用去調用。每一個方法都有成爲服務的潛質，特別是在系統的中後期。領域模型是業務邏輯代碼的施工圖紙，它不僅有利於我們對現有系統業務邏輯的瞭解，也指導未來的架構改造。
頂層架構規劃
以下是頂層架構的俯視圖和剖面圖。第一張圖是俯視圖，整個頂層架構最外層的是功能，中間的是業務操作，內層的是數據。功能對應業務系統的用戶界面，操作對應業務系統的服務，數據對應業務系統的數據存儲，如數據庫。第二張圖是剖面圖，切一刀來看，上層是應用，中層是服務和框架，下層是基礎設施數據中心。從圖中的服務層可以看出，服務的歸類跟業務流程的歸類有很大關係。
網站功能規劃
網站功能規劃就是對功能的重新劃分，對照架構現狀，未來的功能應該如何調整？例如，案例中的國內網站功能規劃，分別畫出了全局功能圖、採購商功能圖、平臺商功能圖和供應商功能圖。其實在做網站功能規劃的時候，更多需要考慮現狀，而不是未來調整的部分，如果沒有很大問題，則不做調整，尊重歷史。因爲有些東西(如名稱)用戶已經使用很久了，調整往往比較難，合理大於準確。
應用規劃
系統是什麼？系統：元素+關係。應用架構是什麼？應用架構=應用+架構。應用就是系統的最小單元，應用分類和應用編號構成了應用關係即應用的架構。如下圖中的案例，應用分類新建框架Fx和公共業務系統CBS ，原有的200多個應用中並沒有這兩個產品線，而是分佈在了不同的業務線中，從而導致重複建設。應用編號是給每個應用分配一個六位的數字ID,如同我們的身份證一樣，頭兩位表示產品線，中間兩位表示子系統，最後兩位表示應用，如100206。 應用編號是應用管理、依賴和追蹤的基礎，集中式日誌和監控框架都使用了應用編號。
SOA規劃
SOA規劃就是接口規劃，它的歸類與商務模型中的業務流程有對應關係。下圖中的案例有五個服務中心：預訂服務、訂單處理服務、產品供應服務、財務結算服務和公共服務。每個服務只需要實現一套自己的邏輯，前臺、後臺、接口、作業小應用等都可以調用，服務的邏輯跟業務邏輯是一致的，修改代碼的時候只需要改一個地方就可以影響所有調用這服務的前端應用。
分層架構
分層架構看似很簡單，但保證整個研發中心都使用統一的分層架構就不容易了。那麼如何保證整個研發中心都使用統一的分層架構，以達到提高編寫代碼效率、保證工程統一性的目的?先簡單介紹當前兩種比較流行的分層架構體系，一種是領域架構:包括倉儲層( Repository Layer)、領域層( Domain Layer)、應用服務層( Application Layer )、表現層( Presentation Layer)和基礎公共層( Infrastructure Layer)，如下圖所示。
另一種是相對傳統地分爲三層包括數據層( Data Layer )、業務邏輯層( Business Layer)和表現層( Presentation Layer)，如下圖所示。
領域架構和三層架構之間有什麼區別?在早期做三層架構的時候，大都以表來驅動,在做領域架構的時候，大都以業務邏輯來驅動，兩者的區別確實比較明顯，但到了現在，如果都以業務邏輯爲中心，那麼兩者並沒有本質區別。當時，筆者所在的公司採用了第二種分層法，我們希望把分層做得極簡，也就是說，哪怕剛畢業進入公司的員工，在分層時基本上也不會亂。相對於第一種分層法， 第二種分層法簡單得多。每一個應用的代碼量都不應該很大，一旦工程變得過大，我們就會把它適當拆分，而不是全部放在一個單體應用裏。總之，分層越簡單，整個軟件結構就越清晰，代碼就越容易統一。把工程做得極簡，纔有利於複製，有利於業務的快速構建，有利於規模化，使系統穩定可靠。
架構實施
做完架構規劃後，就是架構實施落地了。我們的架構實施整體思路是:樹目標、給地圖、立榜樣、抓重點、造文化、建制度、整環境、組建架構部。架構部內部招幾名老程序員，外部招幾個架構師。內部人員走出去，提高眼界。外部牛人請進來，落地瞭解歷史和業務。技術建議是: SOA服務化、基礎設施平臺化、公共業務服務化、加強項目概要設計。當研發團隊達到200 多人、有了幾百個應用，且在故障不斷的情況下，不能與以前一樣沒有設計就開始編碼，而是要加強項目概要設計及評審。後面的補與前面的防，“兩手都要抓， 兩手都要硬”。具體計劃是: Roadmap 分步實施，改造一期、改造二期、改造三期，近細遠粗、實事求是、逐步細化、逐步完善。不斷立技改項目，不斷將技改與業務研發項目相結合，技改即是工單、工單即是技改。避免過多地影響業務，並不斷有業務價值輸出，這是架構改造得以持續實施的關鍵！
後記
以上簡單地介紹了總體架構的編寫方法，我們的編寫思路是先了解業務，建立企業商務模型，主要包括靜態的商務主體、組織架構、動態的商務運作模型和業務流程。再瞭解架構現狀，建立現有信息系統模型，主要包括功能架構、應用架構、數據設計和物理架構。一個是商務，另一個是電子，兩者是整個公司的電子商務系統。然後在企業商務模型和現有系統模型之上建立領域模型,領域模型相對穩定，直接指導接下來的架構規劃，最後一定要落地，即架構實施。