需要注意的是,業務流程並不是工作流程,在領域模型中,業務流程的控制很重要,在上篇的領域模型中我們就忽略了這一點,所以在後面的實現中,出現了一些嚴重的問題,主要是管理員審核 js 許可權申請的業務流程。
public
async task
pass
());
await eventbus.publish(new
messagesentevent() );
}
對應的單元測試**:
[fact]
public
async task
()
造成上面這些問題的原因,就是我們之前畫的業務流程圖太敷衍了,沒有具體的進行細化設計,針對管理員審核 js 許可權申請的業務流程,我們再詳細的畫一下:
可以看到,管理員審核通過 js 許可權申請,js 許可權申請的狀態改為「通過」,再開通 js 許可權,然後持久化 js 許可權申請,最後再訊息通知使用者,整個 js 許可權申請通過的業務流程順序應該是這樣的,對照上面這張圖,再看之前的實現,確實牛頭不對馬尾。
簡單總結下審核通過 js 許可權申請的業務流程順序:
js 許可權申請狀態改為「通過」。
開通 js 許可權。
訊息通知使用者。
namespace
cnblogs.
.domain
public
(string
reason,
intuserid,
string
ip)
if(reason.length > 3000)
if(userid == 0)
this
.reason = reason;
this
.userid = userid;
this
.ip = ip;
this
.status = status.wait;
}public
intid
public
string
reason
public
intuserid
public
status status = status.wait;
public
string
ip public
; private
set; } = datetime.now;
public
string
replycontent
public
; private
set; } public
bool
isactive = true
; public
async task<
bool
>
pass
()
this
.status = status.pass;
this
this
.replycontent = "恭喜您!您的js許可權申請已通過審批。"
; eventbus = ioccontainer.default.resolve
(); await eventbus.publish(new
jspermissionopenedevent() );
return
true
; }
public
bool
deny
(string
replycontent)
this
.status = status.deny;
this
this
.replycontent = $"抱歉!您的js許可權申請沒有被批准,
")}麻煩您重新填寫申請理由。"
; return
true
; }
public
bool
lock
()
this
.status = status.lock;
this
this
; return
true
; }
public
async task
passed
()
eventbus = ioccontainer.default.resolve
(); await eventbus.publish(new
messagesentevent() );
}public
async task
denied
()
eventbus = ioccontainer.default.resolve
(); await eventbus.publish(new
messagesentevent() );
}public
async task
locked
()
eventbus = ioccontainer.default.resolve
(); await eventbus.publish(new
messagesentevent() );}}
}
上面最重要的是開通 js 許可權的執行,因為這是 js 許可權申請最終的執行結果,所以我們後面的操作,都必須建立在其成功的基礎之上,那有人會有疑問:為什麼上面的業務流程順序不是這樣的呢?當申請狀態改為「通過」之後,我們才能去開通 js 許可權,這是開通 js 許可權的前提條件,這時候 js 許可權申請狀態是沒有被持久化的,所以,如果開通 js 許可權失敗,js 許可權申請狀態是不會被儲存的,另外,開通 js 許可權的領域事件並沒有返回值,領域事件一般沒有返回值的設計,它只是去通知事件訂閱者執行,並不一定需要事件訂閱者返回結果給它,那我們如果判斷開通 js 許可權是否執行正確呢?就是通過異常判斷,如果開通 js 許可權的領域事件發生異常,後面的操作也將不會正常執行。
namespace
cnblogs.
.domain
.tests
[fact]
public
async task
()
[fact]
public
async task
()
[fact]
public
async task
()
[fact]
public
async task
() }}
從上面**,我們可以清晰看到業務流程的執行順序,assert.notnull
和assert.true
就相當於應用層中的if
判斷,如果正確,則繼續向下執行。
儘管這個系統很簡單,但 ddd 確實是一種很美妙的藝術。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計,加緊學習了一下,找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd,evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法,本站jdon.com是國內公開最早討論ddd 之一,可訂閱 ddd專題...
DDD(領域驅動設計)
domain 領域 driven 驅動 design 設計 由eric evans最先提出,目的是對軟體所涉及到的領域進行建模,以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識,從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd?1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下,軟體無法快速響應需求和業務的迅速變化,最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...