架構中的分離

taochenpfj發表於2010-05-07
原文網址 : https://www.jdon.com/38840
架構
我的一個專案中，引入了一個類似DDD的分析，然後跟兄弟們就搭手建立，實現程式碼！
但是，在我們建立的過程中，以及不斷的分析中，我們發現全部按照ddd來實現有很多比較牽強，或者說是有點複雜化了，在此表述出來跟同行的xdjm們探討探討。
我們從最開始就用ddd的模式進行業務分析，找出其中的業務物件：實體、值物件、工廠、倉庫、以及類似聚合根的facade物件，用來實現一個簡單的表單自定義功能。這個功能裡面主要是新增表單物件（形象點就是標籤），然後調整這個標籤的擺放位置（layout），以及這個標籤的各種屬性。這個過程中產生的業務就是增刪改查，沒有多少特別的，唉。。。。
但是我們當初在分析的時候，也是按照ddd的架構(或者說是包結構)方式來實現，增加了很多過程物件（這些物件包括ddd裡面的那種分層和物件組，xdjm們可以看看那個ddd sample例子，我忘了地址了，不過在這個論壇裡面有）。
等到我們真正分析業務流程的時候，我發現對上面的實現還是有些用處的，因為我們透過上面的增刪改查處理過程，可以產生我們業務過程中需要的物件，在這裡使用ddd就顯得合理了很多。
所以，我就考慮，一個專案中的分析應該劃分出兩個部分進行實現：一是針對物件的維護（可能就是增刪改查，不必實現ddd的那一整套）；一是按照領域的業務處理，在這裡面我們可以實現不同物件的管理。這裡所講的物件管理不是簡單的增刪改查，而是物件的初始化，資料載入等等，體現在ddd裡面可能就是factory，repository等等，還有就是entity，vo，在一個業務過程裡面，我們可以清楚感覺到一個物件的到底是不是有生命週期，到底是不是一個有特徵的特殊物件，從而確定了實體，而我們在處理這些實體的時候就會自然而然的分離出其中的一些聚合根，如果實在找不到，我們可以用facade模式來替代，以避免產生業務洩露的缺口。
而如果我們把上面的兩個方面混在一起來處理的話，我們就是在第一種情況裡面產生一些迷茫，到底實體在哪裡？值物件在哪裡？都是增刪改查，談什麼實體和值物件啊？如果是那樣的話，我們就不是很清楚的分離業務處理和資料維護。。。
針對這些情況，我覺得分離增刪改查相當有必要，必要到我想把增刪改查用restful來實現，也就是我們的那些跟增刪改查相關的頁面都有統一的呼叫和實現機制，區別就是提交的表單，對應的資料庫表，所有這些東西我們其實不必做太多工作，但是可能會有很多特例，那樣就會增加相應的複雜性了。。。。
業務領域分析就是物件的協作，物件的整合。。。。這點就要具體情況具體分析了。。。。。

小弟在此拋磚引玉了。。。。

相關文章