現代軟體開發和以前的軟體開發有很大的不同，以前軟體一般都會根據業務流程，設計程式的入口和程式的出口，即軟體耦合性很強，隨著軟體技術的不斷發展和DDD領域設計模型的不斷深入研究，在微服務化開發框架的大力推廣下，Docker技術和K8s 技術的普及，新一代的企業應用架構再次革新了軟體行業，
無論是軟體開發者還是應用架構者，我認為只是一個作業角色而已，沒有必要分的太清晰，作為軟體行業從業者，大家都應該具備軟體的設計架構理念，最近深讀了《Microsoft.NET企業級應用架構設計》和《企業應用架構模式》這兩本書，還是啟迪很深，特別是開頭這句話“完美的設計不是保羅萬象無所不有，而是完整自洽不可精簡”，
開啟企業應用架構之旅，首先我們需要有一個專門的架構描述語言工具，就是UML 統一建模語言，這個是也是軟體設計領域被國際公認的標準，后期我會單獨抽出一個章節進行UML建模語言的Knowledge Discovery（探索），本章之談談企業應用架構中對業務拆分的理解，
首先進行分功能分解，分解的原則就是，符合通用開放-關閉原則 ， 將每個業務邏輯模型進行封裝，關閉對該業務的所有業務資料的操作，開放關聯介面或服務，通俗點講，就是我的地盤我管，不允許非授權操作我的資料和業務，所有操作統一介面，
每個業務領域里面，以應用的控制為中心，對業務的活動記錄和業務物體的屬性進行不斷的操作，而這些操作都是基于業務模塊里面定義好的規則進行，這種邏輯有著嚴格的控制，而且這些控制又不依賴外部影響，就是自己的邏輯故事自己來撰寫，同時業務模型對外提供標準的操作說明，而這些操作由 單獨的關聯映射去管理，這樣就可以將自己領域內的事情自己來維護，關聯映射部分，就是負責協調對外的承諾，自己內部無論怎么調整，我對外的承認或關聯不會變，
業務領域拆分，就是把一個生態環境拆分若干模塊，業務生態是千變萬化的，是不斷發展和演變，每天的故事都是不一樣的，而拆分的業務領域模型，就是一個工廠，工廠內的機器控制產品的裝配，產品的包裝，產品的質檢，工廠生產環節不關心外部的事情，外部的事情都由工廠的對外經營負責，自己站好自己的崗，
總結一下，封裝了領域內的故事，開放對外的承諾，專業的事情由專業的模塊處理，業務拆分達到這個目標，就能在整個企業應用架構中保持穩定的架構模型，
您的支持，我的動力！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/447130.html
標籤：架構設計