領域模型實踐中的一手問題

yangfudong發表於2009-09-15
模型
最近公司在做一個專案，公司以前是做C/S的，目前在向Java方面轉型，這個專案在技術BOSS的領導下用領域模型模式實現。
倒是請了些有Java開發經驗的，技術是沒有問題，但以前都用事務指令碼，有很重的資料庫驅動思想，所以對領域模型也不是很在行。
我們在摸索中也克服了一些障礙，但有些問題還沒考慮清楚。今天貼出來希望大家指正和幫助。

業務知識：
報銷病人按政策參保即可享受按比例報銷待遇，每年繳費一次，第二年全年可享受。
管理中心負責本地區報銷相關業務的管理，負責定點醫院的稽核、撥付墊付款，負責域外就醫病人返回時的報銷。
管理中心設定多個報銷定點醫院，域內定點醫院與管理中心聯網出院即報，醫院墊付報銷款，每月與中心結算一次。有些定點醫院使用收費系統與本系統介面，有的定點醫院沒有收費系統，使用本系統提供的功能錄入報銷。域外醫院不出院即報，病人自付，回中心報銷。
管理中心可在下級設定辦事處，負責更小地區的醫院、參保人管理。
各級政府負責本地參保，使用登記系統維護檔案。每年年底進行一次參保，中途不允許參保。

系統目標：
完成一個資料集中邏輯分離的經辦機構管理系統。
最大考慮以省為單位部署系統，每個縣(區)有一個經辦機構，經辦機構數最大可達100-200。

面對4類使用者：
技術部門，系統部署在全省，本公司技術部門負責按需開通管理中心和系統全域性的維護。必要時使用系統。
管理中心和下級辦事處：負責本地區業務的管理、域外病人報銷等。全天使用系統，每個中心10個使用者。
定點醫院：負責本院病人的出院報銷、報銷款墊付、每月與中心結算。每個醫院使用者不多，但醫院很多。
政府：負責參保、維護參保檔案。每年年底使用，短時間強度大。

根據使用使用者、頻度、強度不同，劃分為5個系統，共用一個資料中心，除了中心業務系統其他的都可算是支撐系統，因為只有中心付費，但沒有其他系統中心繫統也運作不起來，所以要實現但要分清重點：
全域性管理系統-技術部門使用。
中心業務系統-管理中心和下級辦事處使用，可以分配許可權。
定點醫院系統-定點醫院使用，關於報銷邏輯、檔案邏輯等在此，其他系統都是呼叫。
介面系統-醫院收費系統和本系統的對接。
參保系統-政府使用。和中心業務系統的檔案是複製關係，不能直接操作。

系統層級劃分：
使用者介面層。使用ExtJS元件，所有元件都做了封裝最佳化，Ajax操作用了一些JQuery的東西。
facade層，即應用層application。負責聯絡使用者介面層和領域層業務邏輯，有事務控制。一般一個使用者介面層介面有一個facade對應。
領域層domain，分為Model、Service、Repository，這裡我們有點分歧，但邏輯都在這個層次是一致的。我認為Model對應領域內的一個實體，Service對應一種關係到多個實體不能簡單併入一個實體的實際業務，Repository是根物件與持久層互動的倉庫。技術BOSS認為Serivice是一個小領域的整體包裝，所有業務都在裡面寫，facade層就和這個Service互動。有些人認為用Dao就可以了，每個Model都有一個Dao，基類Dao裡原來寫好了基本方法，且用泛型直接就拿出了對應的模型，不用轉換，如果用Repository好似還要自己轉換型別，對這種理念也不熟悉。
基礎設施層infrastructure，hibernate、iBatis、jdbc都應該會用到，好像可說的不多。

還沒確定的：
已經決定分為多個系統，那程式碼複用怎麼做？是整體設計domain，然後直接複製貼上或build到其他系統嗎？這樣的話還有下面的問題要考慮：
先分層再分包？這樣每個系統的facade層都直接依賴於domain層。
先分系統包再分層？這樣每個系統包要對外提供一些服務。
還是兩種混合？

考慮幾天沒有頭緒啊，也沒有經驗，各位能否給點意見建議

相關文章