Question

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

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

我试图找出如何在不同的有界上下文中分离域对象。

我想到了可能是员工的域对象。

让我们说我有两个有限的背景，人力资源部和财务部。

通常，财务部门需要有关员工的更多信息，而不是人力资源部门。人力资源部门不需要任何有关员工银行详细信息，国民保险号码或合同时间的信息。（也许在某些业务中，这不是真的，但我们可以在示例中假设这一点。）

因此，在两个单独的上下文中，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 Context有扩展行为。

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

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

我希望每个环境都是有限的。

帮助！

Answer 1

我对您的域名的了解有限，但我可能会在每个有限的上下文中分别对Employee进行建模，即有2个独立的实体，因此它们可以分别进化以匹配每个上下文＆＃39需要。

人力资源部门将控制雇用新员工，修改他们的详细信息（更改名称等），以及减少诸如解雇和使员工多余等美味任务。因此，我很想将主员工记录保存在人力资源系统中，当财务需要了解更新时，我会通过网络服务或消息总线将这些更改推送到其他系统，在财务环境中将Title，Forename，Surname，Address和DateOfBirth等属性设为只读。

Answer 2

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

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

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

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

2 个答案: