演進原則
任何産品的演進都無法一蹴而就，在架構演進過程中需遵循以下幾方面的原則。
- 漸進性原則，滿足目前及未來一定範圍的技術要求，可做到平台的平滑過渡更新。
- 獨立性原則，逐漸拆分的微服務要具有一定的獨立性，以能力方式對上層應用服務提供特定的業務能力支援，要與其他服務保持相對無關性。比如獨立的檔案服務、licence授權服務、工作流服務等等。
- 無狀态原則，微服務要保證基本無狀态，便于微服務自身的叢集建構及獨立疊代優化。
劃分原則
把一個大系統劃分為多個微服務，使子產品間結構更加清晰，子產品間更低耦合高内聚，有更好的擴充性和穩定性。微服務劃分務必遵守以下原則：
- 按功能子產品劃分微服務，盡量做到一個功能子產品一個微服務。
- 微服務之間減少互相調用，做到低耦合高内聚。
項目劃分
- mes-base 共有基礎子產品，抽出共用實體，共用工具類等
- mes-discovery-nacos 服務注冊中心
- mes-api-gateway 網關
- mes-config 配置中心
- mes-user 使用者子產品
- mes-equipment 裝置管理子產品
等等，具體根據業務做具體劃分。
“萬能模闆”是什麼
在雲原生技術實踐聯盟（CNBPA）2021 年初的調研中顯示，國内 72.7%的企業已經采用 Kubernetes 作為容器編排技術，占據了絕對的優勢地位。這也與 CNCF 最新釋出的中國區雲原生調查報告中，72%的受訪者已經在生産環境當中使用 Kubernetes 的資料保持相當高的一緻性，同期全球調查報告的數字是 78%。
在雲計算建設和技術引入時，建議考慮基于以 Kubernetes 為核心的雲原生平台來做，Kubernetes 作為雲的作業系統，可以屏蔽下面各種各樣不同的雲環境、雲基礎設施，它自身是一個可移植層，這樣在做混合雲和多雲管理時，對應用遷移以及其他工作負載非常有好處，可以做到跨環境的相容。由于 Kubernetes 的可擴充性，本身平台之平台的屬性，導緻它天生适合用來作為整個混合雲的控制台，用它去編排不同類型的雲環境以及雲基礎設施和各類雲服務。
在建設路線上應該以應用為中心，覆寫應用全生命周期為目标進行雲計算的建設方向。充分考慮平台融合基礎設施、微服務架構、資料服務、DevOps 工具等子產品作為平台元件，以建設具備全棧能力的雲平台為發展方向。
應用轉型的相關規範
建議可以參考以下 15 個要素，這些要素幾乎涵蓋了雲原生架構下應用轉型的各個方面。
要素 1：基準代碼（Codebase）——一份基準代碼，多份部署。
要素 2：依賴（Dependencies）——顯式地聲明依賴關系。
要素 3：配置（Config）——在環境中存儲配置。
要素 4：後端服務（Backing Services）——把後端服務當作附加資源。
要素 5：建構、釋出、運作（Build、Release、Run）——嚴格分離建構、釋出、運作。
要素 6：程序（Processes）——以一個或多個無狀态程序運作應用。
要素 7：端口綁定（Port Binding）——通過端口綁定提供服務。
要素 8：并發（Concurrency）——通過程序模型進行擴充。
要素 9：易處理（Disposability）——快速啟動和優雅終止可最大化健壯性。
要素 10：開發環境與線上環境等價（Dev and Prod Parity）——盡可能保持開發、預釋出、線上環境相同。
要素 11：日志（Logs）——将日志當作事件流。
要素 12：管理程序（Admin Processes）——将背景管理任務作為一次性程序運作。
要素 13：優先考慮 API 設計（API First）。
要素 14：通過遙測感覺系統狀态（Telemetry）。
要素 15：認證和授權（Authentication and Authorization）
領域劃分的規則或者原則
單一抽象層次原則
這個原則其實要求做領域劃分的時候不可以抽象出多個相似的領域，比如營銷和優惠，這兩個可能就是相似的領域，或者說優惠是在營銷領域下的一個層次的抽象，那這樣的話我們可以用這個原則來檢查一下劃分的領域有沒有可能存在相似和重複。當然另外一方面也可以保障我們可以識别大多數的重要領域。
奧卡姆剃刀原理
這裡說的意思是在劃分上下文的時候不要做的太細，太細的話就存在多個層次的内容反而無法更好的切分上下文，那麼在領域層也類似，說白了，通過這個原理可以讓主觀的劃分更有能動性，也更能給出劃分的理由。即使是拍腦袋劃分的，能從中取出核心的領域名稱并給出具有說服力的理由也算一種劃分方案。
最小驚訝原則
這個原則說的是在真正懂行的專家裡或者有經驗的大佬面前如果你的劃分挺合理的話那麼他們不會感到驚訝，可能會會心一笑。反之就會覺得有需要改進的地方，或者再讨論讨論。是以在領域和上下文的劃分上來看，如果劃分的比較合理那麼就沒有太多争論的必要了。
正交原則
這個正交原則其實可能有點不太了解或者不容易應用，在領域劃分方案出來之後可以通過一些業務流程來看一下領域内的聚合實體服務等是否跟别的領域内做的事情相似或者一樣，如果存在的話說明還可以繼續優化。直到每個領域做的事情都足夠唯一或者職責單一，到合适的正交次元即可。如果過度的追求正交和職責單一可能會出現單一抽象層次不清晰的情況。
多數派原則
簡單解釋一下，就是可以從統一語言或者領域名稱中找一些線索，比如我們有很多業務流程，有很多用例或者使用者故事，那麼這些文檔和業務中哪些出現的名詞或者動名詞最多這個就可以作為一個領域。目前看這是一種最簡單的領域劃分原則了，也就是說你可以從腦海中過一遍所有業務流程，接口流程，調用時序，從統一語言上去統計哪些詞語是最常出現的，這些詞語代表了哪個次元的領域，是核心領域還是通用領域，還是依賴領域等等。那麼可以把這些詞語單獨摘出來去劃分，當然也可能有最多的排序，比如出現詞語最多的有 20 個，但是裡面可能有重複的，不夠正交也不夠單一抽象，那麼可以用排除法一一去舍掉看是否是最好的領域劃分方案，類似于手動尋找最優解。