domain-driven-design - DDD : What kinds of behavior should I put on a domain entity?

Question

我的团队非常努力地坚持将领域驱动设计作为一种架构策略。但是，在大多数情况下，我们的领域实体都非常贫乏。我们希望将更多业务/域行为放在我们的域实体上。
例如，Active Record 对实体进行数据访问。我们不希望这样，因为我们很乐意使用存储库模式进行数据访问。
此外，我们将软件设计为 SOLID(鲍勃叔叔提出的五个软件设计原则)。因此，我们在设计实体时关注单一职责、开闭、liskov、接口(interface)隔离和依赖倒置对我们来说很重要。
那么，我们应该包括哪些行为呢？我们应该远离哪些种类？

Answer 1

我问这个问题已经快一年了，从那时起我和我的团队学到了很多东西。今天我将如何回答这个问题:

域应该代表(在代码中)业务是什么或做什么(在现实生活中)。因此，域实体是在现实生活中发现的工件或参与者。那些现实生活中的人工制品和 Actor 有什么样的行为？所有的。反过来，域实体应该对它们有什么样的行为？所有的。

例如，在现实生活中，经理可以雇用一名新员工。域的表示应该包括像“经理”和“新员工”这样的实体。经理就是 Actor ，在这里。

//newEmployee comes from somewhere else... possibly the UI
//someManagerId comes from the logged in user
var manager = _repository.Get<Manager>(someManagerId);
manager.Hire(newEmployee);

因此，经理实体在这里建模/反射(reflect)了现实生活中的业务行为。另一种方法是跳过经理实体作为 Actor ，并将他推到角落，以便繁重的“域服务”可以完成所有工作......就像这样:

//newEmployeeService comes from somewhere else... possibly injected using IOC
newEmployeeService.Create(newEmployee, someManagerId);

在贫血的域中，您将使用这样的域服务来创建或雇用员工。它有效，但它没有表现力，并且行为不那么容易被发现。谁做了什么？为什么经理需要创建新员工？

我想当我最初问这个问题时，我想尝试开始在我的实体中包含更多行为，但我真的不知道如果不将服务注入(inject)我的实体(例如，使用构造函数注入(inject))。从那时起，我们学到了一些新技巧，并且我们团队的实体具有超强的表现力。简而言之，这是我们正在做的事情:

在可能的情况下，我们尝试使用参与者实体来表达正在执行 Action 的人或事物。

Actor 具有表达他们可以执行的 Action 的方法

当需要服务时，它会作为参数注入(inject)到使用它的方法中。

我们使用 BlingBag 触发域事件在每个域实体上的每个方法上提供可扩展性并赋予实体自我持久的能力。