確定域角色何時需要明確建模的指導

Question

我正在尋找關於何時必須在域模型中明確建模角色的一些準則。

我會在這裏舉一個例子的幫助來解釋我目前的立場。

說，我們正在建立一個醫療系統，與業務需求規定

「有3年以上的經驗，只有醫生和某些 資格可以進行手術」

在這病例很明顯，做手術的行爲只能由扮演醫生角色的人執行，醫生需要滿足某些先決條件才能執行動作

docter.performSurgery() 

所以基本上所有的醫生都不一樣

這種方法可能會檢查，如果條件滿足了

因此，在上述情況下，我會的作用明確建模。

現在讓我們考慮一下備用場景。

只有管理員可以批准資金轉移

在上述情況下，我做不找到任何需要建模域這個角色，因爲他們沒有規則區分另一個管理員在我的領域。

任何人/與管理員的權限USERLOGIN可以執行這個動作，我寧願設計這個到我的安全基礎設施，並確保只有在當前登錄的調用應用層上

approveTransfer()方法被調用用戶具有ADMIN權限。

因此，「域模型」，其中我的意思是像類帳戶類的類是不知道這個規則，這是通過AOP或可能AccountService類或類似編碼在應用程序層。

智者們對此有何評論？ :)

Answer 1

設計聚合時，我總是問自己一個重要的問題。

• 什麼是我試圖建模的過程的一致性邊界？

我問在任何一個原子操作中必須應用什麼規則。這被稱爲事務邊界，當你定義你的不變式時（在原子操作的生命週期中必須始終爲真的規則 - 從頭到尾），你的麪包變成了黃油。

正如我所見，醫生/外科醫生必須具備的規則n年的經驗 - 對於特定的手術 - 是必須始終保持交易一致（例如進行手術時）的不變量。因此，它應該被建模爲單個聚合內的事務邊界。

由於聚合只能保證其內部的一致性，它所負責的不變量不應該泄漏到它之外。在我看來，假設醫生是一個整體，一個單獨的角色模型不應該爲醫生模型本身應負責的不變量負責。

總結聚合關係實際上只應該建立在提供一些缺失信息的'幫助'上。但是規則以及如何解釋這些信息應該在其各自的聚合中被隔離。

用戶身份驗證可能會出現單獨的情況。您可能與Customer模型有關聯，但權限，身份驗證和角色的詳細信息非常龐大，因此需要完全獨立的系統來處理。在這種情況下，您最終可能會爲User Roles and Permission創建單獨的有界上下文並鏈接兩個有界上下文。在這種情況下，您可以擁有一個處理兩者之間通信的域服務。用一個操作調用Customer根，並通過域服務傳遞一些意圖顯示雙重調度，並讓域服務解析操作是否通過。在這種情況下，用戶身份驗證的責任根本不是Customer。 Customer根本不在乎（因爲它本身不能保證交易），並且它最多可以決定要做什麼。

來源：實施領域驅動設計 - 沃恩弗農

正確設計的聚合是一個可以由企業與它的不變量在一個事務中完全一致要求任何方式修改。在所有情況下，正確設計的Bounded Context只會修改每個事務的一個Aggregate實例。更重要的是，我們不能在沒有應用事務分析的情況下正確推理總體設計。