关于业务系统的架构思考
最近參與了很多的業務系統架構的討論,有很多收獲,也發現了很多不同領域的問題或解決方案抽象起來是一致的,這里做下簡單的總結。
一、不能將團隊邊界、領域邊界混為一談
我們的人員是高效利用的,領域與團隊間是不能一一對應的。絕大多數時候領域的邊界是不變的,而團隊的職責在不斷調整,一個團隊也很有可能是因為項目而設置,這個時候不能因為團隊邊界就去改變領域邊界。
當我們遇到"沖突"時,應該先聚焦在領域邊界,忽略團隊邊界,應該從如果大家是一個團隊,大家一起想架構方案會是什么樣的方案。確定了方案后,再思考團隊分工。
大家試試,真的可以解決很多問題哦!
二、架構的核心問題就是分層和邊界問題
分層的本質就是將變化分離,讓每一層獨立變化,不用影響全局。分層可以縮小討論范圍,有利于更聚焦于問題本身。軟件分層還是一種最佳實踐。
這里想強調一下分層和邊界定義對我們這樣工作環境的意義,業務是在發展變化的,軟件一定跟著一起變化,而我們今天的業務形式變化常常會讓你無法在教科書中找到"正確"的架構設計,這個時候分層可以讓我們把確定性的東西想清楚,封裝好。讓我們把精力花在不確定性的地方。
如果我們討論復雜的業務和架構問題時,摸不清頭腦,那就先進行分層,是我個人的實踐方案,感覺很有用
三、架構的核心問題也是問題定義或領域分析的問題
正確的問題定義和領域定義最接近于問題的本質,當然也是對問題發展方向支撐最好的。面向對象設計思想也解釋了這一點,面向對象就是一種能夠讓我們把問題和領域分析清楚的方法。
我這里想突出一種場景,當問題定義錯誤,領域劃分錯誤,這個時候如果有另外的領域依賴了本領域,那就是個災難,這個雷埋給了所有直接或間接信任你的人。
四、架構是一種平衡,不能一刀切
問題的解決方案往往是Hybrid模式的,這個不能理解為妥協。這里面主要想講的跟第一條的核心思路相依,也與第二條相關。就是我們往往不是將軟件分層去討論,而是拿著兩個完整的域或系統去討論,而很多的沖突是不同層之間的。我們應該針對不同層提出不同的解決方案,形成一種Hybrid的方案。最終達到一種非妥協的平衡。
五、大數據時代,架構多了一種選擇,很多可以變成一個優化問題。問題從定性變成了定量。
軟件世界常常存在矛盾,比如CAP的矛盾。但今天在大數據時代,結合實時技術,我們可以將矛盾的某一個方面拿出來,從定性改為定量,經如一致性,假設我們的一致性能做到99.9999%,也能讓一致性影響的用戶范圍永遠小于個位數,可能就夠了,而這個對于一致性的"放棄",很可能節省了巨大的人力和基礎設施成本。這方面AE的區域化部署技術在一致性解決上面就采用了這樣的思路。
總結
以上是生活随笔為你收集整理的关于业务系统的架构思考的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: C# 创建、部署和调用WebServic
- 下一篇: Filesystem has error