领域驱动设计：界限上下文、领域对象

Question

我正在尝试弄清楚如何处理DDD和有界上下文的使用。

我尝试举一个例子来说明我的问题。（为了快速，我使用了贫血类）。

我试图规划如何将不同的有界上下文中的领域对象分离出来。

我考虑了一个可能是Employee的领域对象。

假设我有两个有界上下文，人力资源部门和财务部门。

通常情况下，财务部门需要比人力资源部门更多与Employee相关的信息。人力资源部门不需要任何与员工银行详情、国民保险号或合同小时数有关的信息。（也许在某些企业中，这并不完全正确，但在本示例中我们假设是这样的）。

因此，在两个不同的上下文中，与Employee所需的行为/交互是不同的。

人力资源部门。

public class Employee
    {
        public int Id { get; set; }
        public Title Title { get; set; }
        public string Forename { get; set; }
        public string Surname { get; set; }
        public Address Address { get; set; }
        public DateTime DateOfBrith { get; set; }
        public DateTime EmploymentStartDate { get; set; }

    }

财务部门。

public class Employee
    {
        public int Id { get; set; }
        public Title Title { get; set; }
        public string Forename { get; set; }
        public string Surname { get; set; }
        public Address Address { get; set; }
        public DateTime DateOfBrith { get; set; }
        public string NationalInsuranceNumber { get; set; }
        public BankAccount BankAccountDetails { get; set; }
        public double ContractedHours { get; set; }
}

在这个例子中，我该如何将 HR 上下文中的 Employee 对象限制为仅具有所需行为，并使 Finance 上下文具有扩展行为。

如果应用程序分为多个上下文，每个上下文都与 Employee 相关联具有自定义行为，那么我该如何对 Employee 对象进行建模。

我已经尝试了不同的方法来构建您的上下文映射，共享内核似乎很有前途，但这意味着所有上下文都会共享与 Employee 领域对象相关联的所有行为。

我希望每个上下文都有所限制。

帮帮我！

- Derek

---

这应该对你有帮助 识别边界上下文、聚合、实体和值对象。 - MikeSW

Answer 1

我对你们领域的知识有限，但我可能会在每个界限上单独建模员工，即拥有2个独立的实体，以便它们可以分别发展以满足每个上下文的需求。

人力资源部门将控制雇用新员工、修改员工详细信息（更改姓名等）以及执行不太令人愉快的任务，如解雇和裁员。因此，我倾向于在人力资源系统中保留主要员工记录，在财务需要了解更新时，通过Web服务或消息总线等方式将这些更改推送到其他系统中。在财务上下文中，使职称、名字、姓氏、地址和出生日期等属性只读。

- Adrian Thompson Phillips

---

我猜我遇到的一个问题是，如果你有4个上下文，并且这4个上下文在某种程度上共享一些域模型对象（员工）的行为，那么你最终会重复代码，并且当需要改变行为时，需要进行4次修改，如果这有任何意义的话！ - Derek

是的，这很有道理。DDD方法倾向于产生更多的代码，但复杂度保持不变。 在这种情况下，对一个BC的更改不会影响其他BC。我觉得这很有道理。 附注：更严格的setter属性也很有道理 ;) - BAD_SEED

是的，我刚刚使用了一个不太好的贫血类，因为我只是想获得一个基本的模型对象来进行演示。 - Derek

Answer 2

每个业务组件（BC）都定义了自己的模型。通常，员工（Employee）只在一个BC中作为完整定义的概念存在。其他BC有其自己的定义，并且大部分时间它将是一个ID（使其成为GUID）。在你的例子中，仅在HR中，员工才具有完整实体意义。对于财务部门，您将拥有ID和从财务角度讲有意义的字段。这里没有重复，因为这些模型服务于不同的目的（可以把它看作是重复字母来组成单词，每个单词都是由那些重复字母组合而成，但它们代表不同的概念）。

将BC视为独立的组件（项目、应用程序）。仅因为您在其中一个组件中有一些字段，并不意味着您应该在可能使用这些字段的每个应用程序中重新使用该对象。保持您的模型界限清晰并彼此独立。随着时间的推移，它们很可能会以不同的方式发展。

此外，请问您是否真的需要员工地址或职称或名字/姓氏等信息。您的用例将告诉您实际需要哪些数据。从概念名称开始建模用例，这就是您找出相关属性和行为的方法。记住YAGNI，如果没有用例需要它，那么就不需要对象/字段:D

- MikeSW