專案背景與技術選型
作者主導某 CRM 專案，經對比 .NET、J2EE 等平台，最終選擇 J2EE：成熟穩健、廠商中立、分布式事務/安全/持久化容器托管、XML 聲明式配置、團隊熟悉度高。採用 B/S 架構 (除呼叫中心 C/S)，業務邏輯封裝為 EJB 組件發布至應用服務器，前端 JSP/Servlet 調用。
CRM 五大模塊與業務關係
| 模塊 | 核心功能 | 技術形態 |
|---|
| 市場管理 | 客戶分析、策略規劃、競對跟蹤、營銷評估 | B/S |
| 銷售管理 | 線索/機會/賬戶/合同/報價/訂單、隊伍資源調配 | B/S |
| 服務管理 | 知識庫、工單、滿意度、交叉銷售線索捕捉 | B/S |
| 呼叫中心 | CTI 整合 (DNIS/ANI/IVR)、來電彈屏、銷服一體化 | C/S |
| 電子商務 | 個性化門戶、購買/付款/服務/查詢全流程、與呼叫中心聯動 | B/S |
核心設計原則：以客戶為中心的數據模型與組件復用
- 所有模塊圍繞「客戶」核心實體，共享客戶主數據 (基本信息、購買歷史、投訴、忠誠度等)。
- 模塊間不直接調用接口，而是通過「客戶對象」隱性耦合，降低顯性依賴，提升擴展性。
- 銷售/服務組件復用至呼叫中心、電子商務，減少重複開發，保證邏輯一致性。
J2EE 分層架構落地規範
瀏覽器 → JSP → Servlet → EJB → 數據庫
| 層次 | 技術 | 職責 | 質量紅線 |
|---|
| 表現層 | JSP + JavaBean | 界面渲染、表單綁定、輸入校驗、國際化 | 禁業務邏輯；版面拆分 <jsp:include>；動態內容庫表化；複雜邏輯委託 JavaBean |
| 控制/業務協調層 | Servlet | 請求分發、事務邊界控制、線程安全、連接池管理、Servlet 鏈組合業務 | 實例變量禁用/同步；DataSource JNDI 注入；業務邏輯下沉 EJB |
| 業務邏輯層 | Session Bean + Entity Bean | 核心業務規則、事務管理、安全授權、持久化協調 | static 必須 final；禁文件/網絡/線程/AWT 操作；Session Bean 門面調用 Entity Bean |
技術過程控制：系統分析師為核心的質量把關體系
- 需求理解深度：系統分析師 (SA) 必須透徹業務，將需求分解為獨立、可復用的業務邏輯組件 (粒度：一組件一邏輯)。
- 邏輯嚴密性：SA 具備強邏輯建模能力，設計組件協作序列圖、狀態機，經多輪評審定案。
- 技術掌控力：SA 精通 J2EE 規範與容器行為，編碼階段嚴審代碼 (EJB/Servlet/JSP)，確保規範合規。
- 分工嚴格隔離：
- SA (架構/評審/把關)
- 後端組件開發 (Servlet/EJB)
- 服務器實施/運維 (組件部署/調優)
- 後端測試 (組件級/整合級)
- 前端開發 (JSP/美工/JS)
- 前端測試 (UI/兼容性)
嚴禁前後端角色互換，防止業務邏輯滲透至表現層導致耦合失控。
- 組件復用治理：建立組件庫，註冊接口契約、版本、擁有者，新模塊優先檢索復用。
關鍵技術難點與應對
- 分布式事務：容器管理 (CMT) 為主，跨數據源採用 JTA/XA，業務邊界在 Session Bean 聲明式定義。
- 性能調優：Entity Bean 適當採用 BMP 優化複雜查詢；讀多寫少場景引入二級緩存 (EHCache/JBoss Cache)；SQL 監控與索引優化常態化。
- 集群與會話複製：應用服務器集群配置 Session Replication，或外部化 Session 至 Redis，保障高可用。
- 呼叫中心 CTI 整合：JNI/ JNA 調用廠商 DLL，或採用 JTAPI 標準接口，隔離專有協議變更影響。
國內 CRM 產品常見缺陷與 J2EE 方案對標
| 常見缺陷 | 根因 | J2EE 組件化方案 |
|---|
| 大而全但功能淺薄，不可用 | 缺乏領域建模，功能堆砌 | 領域模型驅動組件設計，每組件封裝單一業務能力 |
| 缺乏集成能力 (郵件/電話/傳真/網頁) | 架構僵化，無統一集成總線 | JMS/EJB 消息驅動 + JavaMail/JTAPI 適配器，統一接入層 |
| 無客戶互動渠道 | 非以客戶為中心設計 | 客戶核心實體 + 多渠道適配器模式，全渠道統一視圖 |
結語
J2EE 平台以成熟規範、容器托管服務、組件化模型，為構建大型、可擴展、可維護的 CRM 系統提供了堅實基礎。但技術從不自動產出成功——系統分析師的業務洞察、架構治理、代碼把關才是項目成敗的關鍵變量。嚴格分工、組件復用、以客戶為核心的數據模型，是將 J2EE 技術紅利轉化為業務價值的必由之路。
