用這麼麻煩嗎？

起因

昨天群裡讨論

@北京-sky 群主大大，有個問題請教一下，現在項目裡看到的分層結構，基本就是controller、service、dao、entity，而service層都很薄，基本就是直接調用dao對表資料進行操作，幾乎看不到面向對象設計裡面的繼承關系、聚合組合關系；那新做一個項目的話，到底怎麼去分層，怎麼搭建面向對象的開發架構

這個不用重複造輪子 單體項目裡邊搞不出什麼花樣

灰灰熊 2020/7/6 星期一 11:26:19 分層本身我覺得沒有問題，關鍵是service層和entity層到底怎麼定義？ 領域模型又可以分為失血、貧血和充血3種。 失血模型：基于資料庫的領域設計方式就是典型的失血模型，隻關注資料的增删改查。 貧血模型：就是在domain object包含了不依賴于持久化的領域邏輯，而那些依賴持久化的領域邏輯被分離到server層。 充血模型：充血模型跟貧血模型差不多，不同的是如何劃分業務邏輯，就是說，約大部分業務應該放到domain object裡面，而service應該是很薄的一層。 到底用充血模型還是貧血模型比較好

業務要持續擴充，會越來越大 根據業務拆分啊

拆分肯定是要做的

先規劃好 多一些設計時間

現在的問題是，面向對象設計和資料庫表結構的設計是有差别的，使用orm可以将表結構轉換成業務實體對象，但是業務實體行為是要與業務實體對象拆分開來放在不同層嗎？

這個看你設計的架構吧 哪種更友善你的業務 擴充行更強

如果業務實體行為與業務實體對象不進行拆分的話，應該是把它們放在service層呢還是放在entity層呢？正常情況下實體就是對象，業務層負責業務邏輯

看來還是不折騰了

領域模型

理論派觀點

•Domain Model是一個商業模組化範疇概念，即使一個企業不開發軟體，也具備其業務模型；•所有同行企業，其業務模型必定有非常大的共性和内在的規律性。•由行業内的各個企業的業務模型再向上抽象出整個行業的業務模型，這個模型稱之為“領域模型”。

實戰派觀點

領域模型是一個分析模型，幫助系統分析人員、使用者認識現實業務的工具，描述的是業務中涉及到的實體及其互相之間的關系，它是需求分析的産物，與問題域相關。是需求分析人員與使用者交流的有力工具，是彼此交流的語言。

常見的三層結構

•Web層（俗稱展現層吧，Presentation Layer)：接收使用者輸入，将資料傳至服務層；•服務層(Service Layer，可以叫Business Logic Layer)：事務邊界，處理業務邏輯、權限管理與授權，并與存儲層通信；•存儲層（Data access layer）：與資料庫進行通信，對資料進行持久化。

但是發現什麼沒有？問題出在了服務層，他承受了太多的職責，像事務管理、業務邏輯、權限檢查等等，這違反了單一職責原則和關注分離原則，并且産生了大量的依賴和循環依賴。當業務複雜度上升時，服務層所包含的代碼将會非常龐大和複雜，直接導緻了測試成本的上升。這裡正好有個例子，在現在的項目中，負責處理保險業務單的核心類中，包含了4000多行代碼，它與資料庫中某一關鍵表相關聯，引用（注入）了十幾個DAO。在數十個各類方法中，可以處理保單、再保、理賠等等各種不同的業務，同時它還深度依賴于hibernate，不但使用了ORM方法處理資料，甚至還直接用了HQL來擷取資料。因為有衆多其他服務類與他進行循環引用，項目後期這個龐然大物已經沒有人敢輕易改動了，因為誰也不知道他到底都能做什麼，重構更是不可能的事。

貧血、失血和充血模型

•失血模型：模型僅僅包含資料的定義和getter/setter方法，業務邏輯和應用邏輯都放到服務層中。這種類在java中叫POJO，在.NET中叫POCO。•貧血模型：貧血模型中包含了一些業務邏輯，但不包含依賴持久層的業務邏輯。這部分依賴于持久層的業務邏輯将會放到服務層中。可以看出，貧血模型中的領域對象是不依賴于持久層的。•充血模型：充血模型中包含了所有的業務邏輯，包括依賴于持久層的業務邏輯。是以，使用充血模型的領域層是依賴于持久層，簡單表示就是UI層->服務層->領域層<->持久層•脹血模型：脹血模型就是把和業務邏輯不想關的其他應用邏輯（如授權、事務等）都放到領域模型中。我感覺脹血模型反而是另外一種的失血模型，因為服務層消失了，領域層幹了服務層的事，到頭來還是什麼都沒變。

從衆心理

從衆心理（conformity），指個人受到外界人群行為的影響，而在自己的知覺、判斷、認識上表現出符合于公衆輿論或多數人的行為方式。實驗表明隻有小部分人能夠保持獨立性，不被從衆，是以從衆心理是部分個體普遍所有的心理現象。

如果你隻是個普通人，那就随波逐流吧，别去彰顯自己的個性，别去反對大部分人都做錯的事情。