回到目錄
規 約(specification)模式:第一次看到這東西是在microsoft nlayer專案中,它是微軟對ddd的解說,就像petshop告訴了我們mvc如何使用一樣,這個規約模式最重要的作用是實現了查詢語句與查詢條件的 分離,查詢語句在底層是穩定的,不變的,而查詢條件是和具體業務,具體領域有關的,是易變的,如果我們為每乙個領域的每乙個新需求都寫乙個新的方法,那就 會出現很多重複的**,不利於程式的最終擴充套件!
下面我們來看乙個經典例子
乙個iorderrepository的介面,定義了乙個訂單倉儲
order_info getorder_infobyid(int**本身沒有任何問題,你只要去實現它就可以了,當乙個新的需求到了之後,你的介面要被擴充套件(這是不被提倡的,一般我們會新建乙個介面),然後修改orderid);
list
getorder_info(datetime from
, datetime to);
list
getorder_infobyuser(int userid);
原來的實現類,去實現介面新的方法(違背了ocp原則),這種做法是大多部開發團隊所經歷了,我,乙個普通的人,也經歷了,但當我知道ddd後,當我看完
microsoft nlayer專案之後,我知道,我一定要改變這種局面,於是,**在規約模式的指導下,進行重構了,呵呵。
先看一下規約模式的類關係圖
下面是我對原來結構的修改(由於原程式是三層架構,所以我就不改變原有架構了,只是對**進行重構,dal層,bll層,web層)
irepository倉儲介面如下,怎麼去實現就不放了,呵呵
publiciorderrepository介面如下inte***ce irepositorywhere tentity : class
in repository
/// ///
list of selected elements
iqueryablegetentities();
//////
get all elements of type that matching a
///specification
/// ///
specification that result meet
///iqueryablegetentities(ispecificationspecification);
//////
通用表示式樹,得到集合
/// ///
///iqueryablegetentities(expressionbool>>predicate);
}
publicdal底層為資料持久化層,它是非常穩定的,只提供最基本的表操作,具體業務如何組成,全放在bll層去實現inte***ce
iorderrepository :
domain.core.irepository
這一層中定義具體業務的規約,並組成查詢方法及呼叫dal層的具體方法(dal層來接受從bll層傳過來的ispecification引數)
//////根據下單日期得到訂單列表
/// public
class orderfromdatespecification : specification
public
override
global::system.linq.expressions.expressionbool>>satisfiedby()
}
///業務層真實的查詢主體,只要在乙個方法裡寫就ok了,然後它非常穩定,如果以後還有其它查詢業務出來,直接新增乙個查詢規約即可///通過使用者資訊得到他的訂單列表
/// public
class orderfromuserspecification : specification
public
override
global::system.linq.expressions.expressionbool>>satisfiedby()
}
///web層建立乙個指定的規約,並為規約元件所需要的資料即可///根據web層傳來及元件好的規約,返回集體
/// ///
///public listgetorder_infobyspec(ispecificationspec)
public actionresult list(int?userid)如果這時來了個新需要,使用使用者名稱進行查詢,你可以直接建立乙個orderfromusernamespecification的規約即可,而不需要修改orderservice,呵呵!
回到目錄
DDD 領域物件與領域服務
什麼是領域物件 什麼是領域服務 領域物件的行為,與領域服務的行為區別 為什麼把這麼小的點拿出來講,最開始在討論中領域物件與領域服務時,覺得行為放在service entity中區別不大,只是乙個放置位置的問題,並不影響到 的抽象和復用,所以沒有實行。但是最近在推動產品進行ddd業務建模,發現這個問題...
DDD之領域服務與領域事件
領域中的服務表示乙個無狀態的操作,它用於實現特定於某個領域的任務。這裡我們要搞清楚什麼樣的操作需要實體,值物件,什麼樣的操作需要採用領域服務。另外,領域服務不是應用服務,在應用服務中我們不需要處理業務邏輯,業務邏輯都落在領域服務中。領域服務發現 領域事件通常是用來與其他聚合解耦的,採用觀察者模式,乙...
DDD領域驅動架構模式
上層 接入層 api層 聚合模組 基礎模組 下層 分層規則 元件名稱 職責entity 實體承載了本領域的所有業務邏輯。實體包含屬性和行為。對乙個領域進行抽象可能會形成多個實體,甚至巢狀的實體 factory 工廠負責將原始資料轉換成實體。原始資料報含 倉庫從資料來源取回的資料 外部傳入的資料 jo...