domain-driven-design - 领域驱动设计限界上下文领域对象

Question

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

我试图想出一个例子来说明我的问题。 (我正在使用贫血类来提高速度)。

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

我想到了可以是 Employee 的域对象。

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

一般来说，财务部门比人力资源部门需要更多关于员工的信息。人力资源部不需要任何与员工银行详细信息、国民保险号码或契约(Contract)工时相关的信息。 (也许在某些企业中这并不完全正确，但让我们在示例中假设这一点)。

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

人力资源部。

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 对象建模。

我研究了构建上下文映射的不同方法，共享内核似乎很有前途，但这意味着所有上下文随后将共享与员工域对象关联的所有行为。

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

帮助!

Answer 1

每个 BC 定义自己的模型。通常，Employee 仅在一个 BC 中是一个完整定义的概念。其他 BC 对它有自己的定义，大多数时候它将是一个 id(使其成为 GUID)。在您的示例中， Employee 仅在 HR 中作为完整实体存在才有意义。对于财务，您将拥有一个 ID 和从财务角度来看有意义的字段。这里没有重复，因为模型有不同的用途(可以把它想象成重复字母组成一个词，每个词都是这些重复字母的组合，但它代表不同的概念)。

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

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