有界上下文和聚合根文件

我們試圖使用DDD原則對基於RBAC的用戶維護系統建模。我們已經確定了以下實體：有界上下文和聚合根文件

Authorization is an Aggregate Root with the following: 
    User (an entity object) 
    List<Authority> (list of value objects) 

Authority contains the following value objects: 
    AuthorityType (base class of classes Role and Permission) 
    effectiveDate 

Role contains a List<Permission> 
Permission has code and description attributes

在一般情況下，授權肯定是聚合根，因爲一切都在用戶維修圍繞那（例如我可以向用戶授予一個或多個機構，非法入境者既不是一個角色或權限）

我的問題是：角色和權限呢？他們是否也在各自獨立的背景下聚合根？（即我有三個上下文，授權，角色，許可）。雖然可以將所有內容合併到一個上下文中，但角色不會太重，因爲它將作爲授權「對象圖」的一部分進行加載？

來源

2012-07-04 jett

首先，我不禁感到你誤解了有界上下文的概念。你所描述的作爲BC的我將描述爲實體。在我看來，有界的上下文有助於爲無處不在的語言中定義的實體針對特定環境提供不同的目的。

例如，在醫院域，患者正在門診收治可能介紹人，和方法的列表，如BookAppointment（）。 A 患者被視爲住院患者但是，將有病房財產和方法，如TransferToTheatre（）。鑑於此，患者存在兩種有限背景：門診病人&住院病人。在保險領域，銷售團隊制定了一個政策，它有一定程度的風險與其相關的成本。但是，如果它到達索賠部門，那麼這些信息對他們毫無意義。他們只需要驗證該政策對索賠是否有效。因此，這裏有兩種情況：銷售&索賠

其次，您是否正在使用RBAC作爲示例，同時嘗試實施DDD？我問的原因是因爲DDD旨在幫助解決複雜的業務問題 - 即需要進行計算（例如策略風險）的情況。在我看來，RBAC是一個相當簡單的基礎架構服務，它並不關心實際的域邏輯，因此不需要嚴格的DDD實現。 DDD的投資成本很高，你不應該爲此而採用它;這就是有界上下文很重要的原因 - 只有在合理的情況下才能用DDD對上下文進行建模。

無論如何，在這個答案聽起來到的風險「學術」我現在就試着回答你的問題假設你仍然要建模以此爲DDD：

對我來說，這將所有適合下一個上下文（所謂的「安全」或東西）

根據經驗，一般規則，讓一切都需要一個獨立的交易聚集，所以：

在假設系統允許當局將被添加到授權對象，使授權一個聚合。（雖然有可能是開溝授權和簡單地使用戶總根與當局列表參數）
當局服務沒有意義的授權骨料的外面，纔會創建時加一個，所以這些仍然是實體。
在假設系統允許權限被添加到一個角色，角色成爲聚合根。
假設權限不能被創建/刪除 - 即它們是由系統本身定義的，所以這些都是簡單的值對象。

雖然在總體設計的主題，我不能推薦這些articles足夠。

來源

2012-07-05 12:24:34

再次感謝大衛。你的陳述「有界的上下文有助於爲無處不在的語言中定義的實體在特定環境下的不同目的」向我明確表達。我想，一開始就讓我感到困惑的是，必須通過AR來訪問其中的一個EO/VO。這是令人困惑的，因爲，正如你所提到的，角色也是授權AR中引用的AR。我們正在參加RBAC練習，以便了解使用DDD的情況。我們正在研究的其他背景是我認爲適用於DDD。 – jett

沒問題。我給出的另一條建議是：**讓聚合通過引用其ID來引用其他聚合，而不是聚合本身**。如果你閱讀我建議的文章解釋了原因。 –

我喜歡這個例子，讓我清楚地理解上下文 –

有界上下文和聚合根文件

回答

相關問題