核心原則
模塊劃分遵循高內聚、低耦合，根據業務邊界、技術職責、部署需求分層。
常見分層方案
| 模塊 | 職責 | 打包形式 | 依賴關係 |
|---|
| common / core | 工具類、常量、基礎實體、異常定義 | JAR | 被所有模塊依賴 |
| dao / repository | 數據訪問層 | JAR | 依賴 common |
| service | 業務邏輯層 | JAR / WAR | 依賴 dao, common |
| web / controller | 控制層、視圖模板 | WAR | 依賴 service, common |
演進階段
階段一：單體應用（適合中小項目）
- 所有代碼在一個 Maven/Gradle 模塊，打成單一 WAR。
- 優點：開發部署簡單，事務管理容易。
- 缺點：耦合度高，團隊協作衝突多，技術棧鎖定。
階段二：多模塊單體（推薦起步）
- 按上述分層拆分為多個 Maven 模塊，最終仍打包為一個 WAR 部署。
- 優點：代碼隔離清晰，便於單元測試，為後續微服務奠基。
- 關鍵：`service` 層接口定義在單獨 API 模塊，`web` 依賴 API 而非實現。
階段三：分布式微服務（業務增長期）
- 將 `service` 拆分為獨立微服務（如 `user-service`、`order-service`），通過 Dubbo / Spring Cloud 註冊發現。
- `web` 變為網關或 BFF 層，聚合下游服務。
- Session 共享：Redis 集中式 Session、JWT 無狀態 Token、或 Spring Session + Redis。
關鍵技術點
- 公共依賴管理：使用 `dependencyManagement` 統一版本，避免 JAR 衝突。
- 接口與實現分離：`service-api` 只含接口/DTO，`service-impl` 含實現，`web` 僅依賴 api。
- 配置外部化：Nacos / Apollo 管理配置，環境隔離。
- 分布式事務：Seata AT 模式或本地消息表實現最終一致性。
- 鏈路追蹤：SkyWalking / Zipkin 監控調用鏈。
避坑指南
- 不要過早拆分微服務，團隊規模 < 20 人時多模塊單體更高效。
- 拒絕循環依賴：`common` 不依賴任何業務模塊。
- 數據庫拆分比服務拆分更難，優先垂直拆表，再考慮分庫。
- 保持 `web` 模塊輕量，不包含業務邏輯，僅做參數校驗、視圖渲染、聚合調用。
總結
「先模塊化，後服務化」是穩健演進路徑。以 `common`、`dao`、`service`、`web` 四層為基礎，根據業務複雜度逐步抽離微服務，配合註冊中心、配置中心、分布式事務、鏈路追蹤等基礎設施，構建可演進的企業級架構。
