DDD 領域服務的規約模式

2021-09-06 13:05:34 字數 2530 閱讀 3342

回到目錄

規 約(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倉儲介面如下,怎麼去實現就不放了,呵呵

public

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);

}

iorderrepository介面如下

public

inte***ce

iorderrepository :

domain.core.irepository

dal底層為資料持久化層,它是非常穩定的,只提供最基本的表操作,具體業務如何組成,全放在bll層去實現

這一層中定義具體業務的規約,並組成查詢方法及呼叫dal層的具體方法(dal層來接受從bll層傳過來的ispecification引數)

///

///根據下單日期得到訂單列表

/// public

class orderfromdatespecification : specification

public

override

global::system.linq.expressions.expressionbool>>satisfiedby()

}

///

///通過使用者資訊得到他的訂單列表

/// public

class orderfromuserspecification : specification

public

override

global::system.linq.expressions.expressionbool>>satisfiedby()

}

業務層真實的查詢主體,只要在乙個方法裡寫就ok了,然後它非常穩定,如果以後還有其它查詢業務出來,直接新增乙個查詢規約即可

///

///根據web層傳來及元件好的規約,返回集體

/// ///

///public listgetorder_infobyspec(ispecificationspec)

web層建立乙個指定的規約,並為規約元件所需要的資料即可

public actionresult list(int?userid)

如果這時來了個新需要,使用使用者名稱進行查詢,你可以直接建立乙個orderfromusernamespecification的規約即可,而不需要修改orderservice,呵呵!

回到目錄

DDD 領域物件與領域服務

什麼是領域物件 什麼是領域服務 領域物件的行為,與領域服務的行為區別 為什麼把這麼小的點拿出來講,最開始在討論中領域物件與領域服務時,覺得行為放在service entity中區別不大,只是乙個放置位置的問題,並不影響到 的抽象和復用,所以沒有實行。但是最近在推動產品進行ddd業務建模,發現這個問題...

DDD之領域服務與領域事件

領域中的服務表示乙個無狀態的操作,它用於實現特定於某個領域的任務。這裡我們要搞清楚什麼樣的操作需要實體,值物件,什麼樣的操作需要採用領域服務。另外,領域服務不是應用服務,在應用服務中我們不需要處理業務邏輯,業務邏輯都落在領域服務中。領域服務發現 領域事件通常是用來與其他聚合解耦的,採用觀察者模式,乙...

DDD領域驅動架構模式

上層 接入層 api層 聚合模組 基礎模組 下層 分層規則 元件名稱 職責entity 實體承載了本領域的所有業務邏輯。實體包含屬性和行為。對乙個領域進行抽象可能會形成多個實體,甚至巢狀的實體 factory 工廠負責將原始資料轉換成實體。原始資料報含 倉庫從資料來源取回的資料 外部傳入的資料 jo...