DDD：我应该对域实体采取哪种行为？ [英] DDD: What kinds of behavior should I put on a domain entity?

问题描述

我的团队非常努力地坚持将域驱动设计作为一种体系结构策略。但是，在大多数情况下，我们的域实体非常虚伪。我们想在域实体中增加更多的业务/域行为。

My team tries very hard to stick to Domain Driven Design as an architectural strategy. But, most of the time, our domain entities are pretty enimic. We'd like to be putting more business/domain behavior on our domain entities.

例如，Active Record将数据访问放在实体上。我们不希望这样，因为我们很乐意使用存储库模式进行数据访问。

For example, Active Record puts data access on the entity. We don't want that because we happily use the repository pattern for data access.

此外，我们将软件设计为SOLID（鲍勃叔叔提出的五项软件设计原则）。因此，对我们很重要，在设计实体时，我们要注意单一责任，开放式，封闭式，liskov，接口隔离和依赖关系倒置。

Also, we design our software to be SOLID (the five software design principles that Uncle Bob put together). So, it's important to us that we pay attention to single responsibility, open-closed, liskov, interface segregation, and dependency inversion while designing our entities.

那么，我们应该包括哪些行为？

So, what kinds of behavior should we include? What kinds should we stay away from?

推荐答案

我问了这个问题已经快一年了，而我和我的团队已经学会了从那以后很多。今天，我将按照以下方式回答这个问题：

It's been almost a year since I asked this question and I and my team have learned quite a lot since then. Here's how I would answer this question today:

域应（以代码形式）代表业务（在现实生活中）或做什么。那么，领域实体就是在现实生活中发现的工件或参与者。这些遗物和演员有什么样的行为？所有的。反过来，域实体应该对它们采取什么样的行为？所有这些。

The domain should represent (in code) what the business is or does (in real life). Domain entities, then, are the artifacts or actors found in that real-life business. What kind of behavior do those rea-life artifacts and actors have? All of it. In turn, what kind of behavior SHOULD domain entities have on them? All of it.

例如，在现实生活中，经理可以雇用新员工。域的表示形式应包括经理和新员工之类的实体。经理是演员，在这里。

For instance, in real life, a manager can hire a new employee. The domain's representation of that should include entities like "manager" and "new employee". The manager is the actor, here.

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

因此，管理者实体在此处建模/反映了真实业务的行为。另一种选择是跳过经理实体，充当演员，然后将他推到角落，这样繁重的域服务就可以完成所有工作...像这样：

So, the manager entity models/reflects the behavior of the real-life business, here. The alternative is to skip the manager entity as an actor, and push him off to the corner so a heavy-lifting "domain service" can do all the work... like this:

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

在贫瘠的域中，您将使用像这样的域服务来创建或雇用员工。它可以工作，但不具有表达能力，行为也不那么容易被发现。谁做了什么？为什么经理需要创建新员工？

In an anemic domain, you would use a domain service like this to create or hire an employee. It works, but it's not expressive and the behavior is not as discoverable. Who does what? Why is the manager required to create a new employee?

我想当我最初问这个问题时，我想尝试一下开始在我的实体中包含更多行为，但是我真的不知道如何不将服务注入到我的实体中（例如，使用构造函数注入）。从那时起，我们学会了一些新技巧，而我们团队的实体则表现力十足。简而言之，这就是我们正在做的事情：

I think when I asked the question originally, I wanted to try to start including more behavior in my entities, but I really didn't know how without injecting services into my entities (for instance, with constructor injection). Since then, we've learned some new tricks and our team's entities are super-expressive. Here's, in a nutshell, what we are doing:

1. 在可能的情况下，我们尝试使用参与者实体来表达所表达的人或事物


2. 演员具有表示他们可以执行的动作的方法


3. 需要服务时，会将其作为参数注入


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

1. We try to, when possible, use actor entities to express the person or thing that is performing the action.
2. Actors have methods that express the actions they can perform
3. When a service is needed, it is injected as an argument in the method where it is used.
4. We fire domain events using BlingBag on every method on every domain entity to provide extensibility and give entities the ability to self-persist.

这篇关于DDD：我应该对域实体采取哪种行为？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！