Question

我试图了解实体如何在多个有界上下文中运行。

给予公司员工。在（例如）人力资源上下文中，此人具有姓名，地址，工资参考编号和银行帐户。但在会计方面，所有相关的是工资参考编号和银行账户。

您在HR上下文中是否有Employee实体，在Accounting上下文中是否有Value-Type（例如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（??）：Employee的value-type

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

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

有界上下文中的HRService是否会返回此信息？或者你在两种情况下都使用Employee类？

Answer 1

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

有界上下文是自治组件，具有自己的域模型和自己无处不在的语言。它们在运行时不应该彼此依赖，并且应该能够单独运行。但是它们是同一整个系统的一部分，并且需要彼此交换数据。

如果您在有界上下文中实现 CQRS pattern ，则应该使用事件进行此类通信：您的有界上下文可以响应在有界上下文之外引发的事件，并且您的有界上下文可以发布其他有界上下文可能订阅的事件。事件（发布已经发生的事情的信息的单向异步消息）使您能够维持有界上下文之间的松散耦合。

Answer 2

如果它们是严格分开的，我会将它们严格分开。不同命名空间中的两个不同类。每个都有不同的属性。

如果人力资源部门创建了一个HRM.Employee，则可能会引发会计核算并创建Accounting.Employee的事件。

Answer 3

如果需要多个上下文，肯定有些事情可以在某些上下文中建模为实体，在另一个上下文中建模为值对象。从实体到值对象的转换通常很简单，但从值对象到实体可能并不那么简单。来自Domain Driven Design，p。 337：

翻译机制不是由模型驱动的。它不在有界的背景。（这是边界本身的一部分，将是在上下文图中讨论。）

如果人力资源环境需要向会计上下文询问有关特定员工的问题，那么这将成为一个令人困惑的问题。

Answer 4

我想我不会在两个上下文中使用相同的实体。它们应该是有界的。如果我必须根据一个上下文的需要更改我的员工类怎么办？...“应该是有限的上下文”不再是那个有限的了。

我会使用一个值对象。诀窍是正确定义值对象。我看到那些等价于“数据类型”的对象，就像整数是一个整数。这当然是有挑战性的（int16，int32 ......）。但我们假设是这样的。员工是价值对象的合适人选吗？......我不这么认为：（......在有限的上下文中，您可能不需要为员工提供相同的信息。另一个名称，员工的身份信息是更好的候选人（名字，姓氏，中间名......）你可以在有界的上下文中重用。

现在服务层应该返回这个值对象吗？... Personnaly我不会这样做。我希望在我的存储库中定义这种可重用性。在Nhibernate中共享映射或共享相同的投影/映射器类。

希望这会有所帮助：）

域驱动设计中有限上下文中的实体

4 个答案: