领域驱动设计有界上下文领域对象答案

【问题标题】：Domain Driven Design Bounded Context Domain Objects领域驱动设计有界上下文领域对象
【发布时间】：2015-01-06 17:35:12
【问题描述】：

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

我试图举一个例子来说明我的问题。（我正在使用贫血的课程来提高速度）。

我正在尝试规划如何在不同的有界上下文中分离域对象。

我想到了可以是 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 对象，使其仅具有所需的行为，并且财务上下文具有扩展行为。

如果一个应用程序被分解为多个上下文，所有上下文都具有与 Employee 关联的自定义行为，我将如何为 Employee 对象建模。

我研究了构建上下文映射的不同方法，共享内核似乎很有希望，但这意味着所有上下文将共享与 Employee Domain 对象关联的所有行为。

我希望每个上下文都会受到限制。

救命！

【问题讨论】：

这对你也有帮助Identifying Bounded Contexts and Aggregates, Entities and Value Objects

标签： domain-driven-design bounded-contexts

【解决方案1】：

我对您的领域的了解有限，但我可能会在每个有界上下文中分别对 Employee 建模，即有 2 个单独的实体，因此它们可以分别发展以满足每个上下文的需求。

HR 将控制雇用新员工、修改他们的详细信息（更改姓名等）以及解雇和裁员等不那么有趣的任务。因此，我很想将主要员工记录保存在 HR 系统中，当财务需要了解的更新发生时，我会通过 Web 服务或消息总线等将这些更改推送到其他系统。在金融环境中将Title、Forename、Surname、Address 和DateOfBirth 等属性设为只读。

【讨论】：

我想我有一个问题，如果你有 4 个上下文，并且所有 4 个在某种程度上共享一些域模型对象（员工）行为，你最终会重复代码，如果需要在行为上进行更改，则需要进行 4 次，如果这有意义的话！
是的，这是有道理的。 DDD 方法往往会产生更多的代码，但具有恒定的复杂性。在这种情况下，对 BC 的更改不会影响其他人。我感觉合理。 PS：限制性更强的 setter 属性，也很有意义 ;)
是的，我刚刚使用了一个肮脏的贫血类，因为我只是想获得一个基本的模型对象进行演示。

【解决方案2】：

每个 BC 都定义了自己的模型。通常，Employee 是一个完整定义的概念，仅在一个 BC 中。其他 BC 对其有自己的定义，并且大多数情况下它将是一个 id（使其成为 GUID）。在您的示例中，员工仅在 HR 中作为完整实体存在才有意义。对于财务，您将拥有一个 ID 和从财务角度来看有意义的字段。这里没有重复，因为模型服务于不同的目的（将其视为重复的字母组成一个单词，每个单词都是这些重复字母的组合，但它代表不同的概念）。

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

另外，问问自己财务是否真的需要员工地址或头衔或名字/姓氏。您的用例会告诉您真正需要哪些数据。从概念名称开始并为用例建模，这就是您找出相关属性和行为的方式。记住 YAGNI ，如果它没有用例，那么就没有对象/字段：D

【讨论】：