域驅動設計中有界上下文的實體

我想了解實體如何在多個有界的上下文中操作。域驅動設計中有界上下文的實體

給定公司的員工。在（例如）人力資源環境中，此人具有姓名，地址，工資參考號和銀行賬戶。但在會計環境中，所有相關的都是薪資參考號碼和銀行賬戶。

您是否在HR環境中有一個員工實體，並且在會計環境中有值類型（例如SalariedEmployee）？

class Employee 
{ 
    public BankAccount BankAcountDetails { get; set; } 
    public string FullName { get; set; } 
    public Address ResidentialAddress { get; set; } 
    public string SalaryRef { get; set; } 
}

SalariedEmployee類（??）：員工的價值型

class SalariedEmployee 
{ 
    public SalariedEmployee(string salaryRef, BankAccount bankAcountDetails) 
    { 
     ... 
    } 

    public string SalaryRef { get; } 
    public BankAccount BankAcountDetails { get; } 
}

是否在界上下文的HRService返回此信息？或者你在上下文中使用Employee類？

來源

2011-11-23 Asher

我想我不會在這兩種情況下使用相同的實體。他們應該是有界的。如果我必須改變我的員工類別以滿足一個上下文的需要，那該怎麼辦？......「應該是有限上下文」不再那麼有限。

我會使用一個值對象。訣竅是正確定義值對象。我看到那些相當於「數據類型」的對象，就像一個整數是一個整數。當然這是有挑戰性的（int16，int32 ...）。但讓我們假設是這樣。僱員是否是價值對象的合適人選？......我不這麼認爲：（......您可能不需要在有限的上下文中爲員工提供相同的信息集合，而在另一個名稱中，僱員的標識信息是更好的候選人（名字，姓氏，中間名......）這可以重用在有限的上下文中。

現在應該服務層返回這個值對象嗎？... Personnaly我不會這樣做，我寧願有這個在我的倉庫中定義的可重用性。共享映射NHibernate的或共享相同的投影/映射器類。

希望這有助於:)

來源

2011-11-24 10:07:01

如果需要多個上下文，肯定有些東西可以在某些上下文中建模爲實體，而在另一個上下文中可以建立值對象。從一個實體到一個值對象的轉換通常是直接的，但是從一個值對象到一個實體可能並不那麼簡單。從Domain Driven Design，p。 337：

翻譯機制不是由模型驅動的。它不在有界的上下文中。（這是邊界本身，這將在語境映射來討論的一部分。）

如果人力資源方面日益需要向會計背景下，有關特定僱員的問題，它會成爲一個令人困惑的問題。

來源

2011-11-23 16:19:09

您是否在說我上面給出的例子是一個好主意，或者它在DDD中是「可允許的」且常見的？ – Asher

這是個好主意。它非常清楚地表明，就任何業務邏輯而言，會計背景不區分受薪僱員。你只需要確信會計環境永遠不需要區分它們。 –

如果他們是嚴格分開的，我會讓他們嚴格分開。兩個不同的類在不同的命名空間中。每個都有不同的屬性。

如果人力資源部門創建HRM.Employee，那麼可能會引發一個事件，即Accounting會選擇並創建一個Accounting.Employee。

來源

2012-07-24 12:45:13 Jeroen

從http://msdn.microsoft.com/en-us/library/jj554200.aspx：

限界上下文是自治的成分，用自己的域模型和他們自己的通用語言。它們在運行時不應該彼此依賴，應該能夠獨立運行。但它們是同一整體系統的一部分，並且需要彼此交換數據。

如果你是在一個有限範圍內實施CQRS pattern，你應該使用事件這種類型的通信：你的限界上下文可以到被提出的有界上下文之外的事件作出反應，你的限界上下文可以發佈事件其他有界的上下文可能會訂閱。事件（發佈關於已發生的事情的信息的單向異步消息）使您能夠維持有界上下文之間的鬆散耦合。

來源

2013-09-10 09:14:38

域驅動設計中有界上下文的實體

回答

相關問題