系統要求 C/S架構的單體桌面應用，可以滿足客戶個性化需求，易於升級和維護。相比於一代Winform，界面要求美觀，控制項豐富可定製。 解決方案 依托.Net6開發平臺，採用模塊化思想設計(即分而治之的策略)，每個模塊採用DDD分層設計。前端選用WPF + Prism框架，後端選用ABP + EF框架 ...
系統要求
C/S架構的單體桌面應用，可以滿足客戶個性化需求，易於升級和維護。相比於一代Winform，界面要求美觀，控制項豐富可定製。
解決方案
依托.Net6開發平臺，採用模塊化思想設計(即分而治之的策略)，每個模塊採用DDD分層設計。前端選用WPF + Prism框架，後端選用ABP + EF框架，資料庫選擇SQL Server。
業務拆分
核心領域：包含用戶管理、客戶管理、表具管理、方案管理、抄表管理
通用領域：包含許可權、菜單、個人中心、參數配置、審計日誌、數據字典
支撐領域：包含數據查詢、統計報表、消息管理、STS安全、工單、自動升級
業務建模
通過業務拆分，水務領域已經被劃分為若幹子領域(即模塊)。每個模塊可以看成是一個限界上下文，在此邊界內可以進一步拆分更細粒度的單元(我們把最小的業務單元叫做聚合)。一個模塊也可能只有一個聚合，如：數據字典。
先拿簡單的用戶管理來說，用戶(User)、角色(Role)、組織(Organization)三者關係緊密、彼此協作。一個用戶可以擁有多個角色，一個組織可以擁有多個用戶，因此可以歸屬到用戶限界上下文，它們既是實體又是聚合根。
再拿複雜一點的客戶管理來說，客戶可分為預付費和後付費兩種。對於預付費客戶來說，可以按量或按金額購水。對於後付費客戶來說，每月會生成一筆月賬單，客戶需要及時充值，否則就會欠費。因此，在客戶這個業務邊界內，可以確定客戶(Customer)、客戶類型(CustomerType)、交易記錄(Transactions)、月賬單(MonthlyBilling)等領域對象。其中水費的計算是一個非常複雜的業務邏輯，涉及到階梯價格、附加費、債務、當月曆史售水交易等多個領域實體，所以需要藉助領域服務來完成這筆交易。
系統設計
系統設計包含兩部分：全局設計和局部設計。
全局設計是從框架角度來進行整體設計。系統框圖如下：
虛線框部分為筆者設計的Lapis.Framework框架，文件組織結構如下：
其中，Laison.Lapis.XXX文件夾代表基礎業務模塊(Laison.Lapis.Shared除外)，如：審計日誌、消息管理等，每個模塊就是一個獨立的C#解決方案。Laison.Lapis是一個底層類庫，封裝各種通用基礎功能，供上層調用。Laison.Lapis.Shared稱之為共用模塊，用於封裝和業務無關，可以被業務模塊共用使用的功能，如: 抽象基類、介面、虛方法等。因為是單體應用設計，所以模塊之間少不了相互引用的關係。模塊劃分越多，引用關係也會變得越複雜。
局部設計是從業務角度來進行模塊設計，每個模塊按照DDD來分層：基礎設施層、領域層、應用層和表現層。下麵是用戶管理模塊(Laison.Lapis.Identity)的分層設計：
Laison.Lapis.Identity.UI：表現層，包含前端頁面、控制項和一些UI邏輯。
Laison.Lapis.Identity.Application.Contracts：應用介面層，負責定義應用介面和DTO。
Laison.Lapis.Identity.Application：應用層，用於實現應用介面，包含各種應用邏輯。
Laison.Lapis.Identity.Domain：領域層，負責業務邏輯處理，包含實體、值對象、倉儲介面等領域模型。
Laison.Lapis.Identity.Domain.Shared：領域共用層，包含了一些枚舉和常量的定義，可供其它任意層調用。
Laison.Lapis.Identity.EntityFramework：實體框架層(EF)，包含實體的映射配置和倉儲的實現。
Laison.Lapis.Identity.HttpApi.Host 和 Laison.Lapis.Identity.Shell：即宿主和殼，分別用來啟動前/後端應用程式。
在ABP框架的世界里，每一分層就是一個模塊單元，它是代碼層面的模塊，而Identity是業務層面的模塊，後者包含前者，最終以DLL的形式來呈現。
系統如何運行
每個模塊負責自己的業務功能，各司其職，又彼此依賴。模塊劃分越細，內聚性越強，代碼的復用性就越高。 當系統要完整運行所有功能時，只需要像搭積木一樣，把各個模塊進行組裝就行，做到即插即用。為了方便代碼復用和管理，筆者採用Nuget包的形式將業務模塊引入到項目中使用，這在開發初期似乎沒有什麼問題。但隨著系統不斷迭代，模塊數量也再隨之增長。假設1個模塊會生成6個DLL(採用DDD分層)，那麼20個模塊就會有120個DLL，聽上去有點嚇人。每次模塊發生變化，就要重新打包、發佈、升級120個Nuget包，這顯然不符合常理(非常耗時)。後來筆者採取了一種折中的處理方式：將通用穩定性強的模塊保留在Lapis.Framework中，把易於變化的模塊下沉到項目中管理，這樣就能避免之前的尷尬，但卻犧牲了模塊代碼的復用性。項目最終代碼結構如下：
個性化定製
企業個性化功能定製是一個普遍而又繞不開的話題，假如能用一套代碼把所有客戶的需求全部覆蓋，當然是最理想的狀態(現實幾乎不可能，除非通用標準化)。所以筆者從設計一開始就是圍繞如何提高代碼的復用，將差異化分散到項目中的思路來展開，這也是採用模塊化設計的初衷。至於個性化如何來實施？根據筆者已知的做法有以下兩種：1. 通過版本管理開分支的方式，2. 簡單粗暴，每個項目都單獨複製一套標準版，然後在上面做定製化修改。 除此之外，筆者似乎沒有想到更好的辦法。至於選擇哪一種，就要根據項目實際情況來考量。
結束語
無論是模塊化設計還是DDD，都是強調從業務領域角度出發，根據業務的發展，合理劃分業務邊界，採用分治策略，降低業務和軟體開發的複雜度，持續調整現有架構，以保持架構和代碼的生命力。 因此，世界上並不存在一勞永逸的架構，軟體設計本身就是一個平衡取捨的過程，只有合適的才是最好的，這也許就是架構設計的魅力所在吧！如果你有好的建議或不同想法，歡迎評論區留言。
