实体和 DTO 是否始终是 DDD 的强制要求答案

【问题标题】：Are entity and DTO always mandatory for DDD实体和 DTO 是否始终是 DDD 的强制要求
【发布时间】：2016-10-19 08:11:30
【问题描述】：

我是领域驱动设计的新手。目前我有大约 5 个 bean，它们之间有一个层次结构。严格来说，bean 是 DTO。但是，我会将它们从域层返回到服务层和控制器。这对我来说一直很好，但是根据域驱动设计，域层必须返回 BO，服务必须返回控制器将映射到 DTO 的 DTO 或 BO。我没有看到这一点，因为最后我会将服务返回的对象转换为 JSON，它只是数据。那么我真的有必要拥有单独的 BO 和 DTO。

请注意，我有一个无状态业务对象，它执行特定业务功能的所有操作并根据需要返回多个 DTO。如果我走在正确的道路上，请提供建议。

【问题讨论】：

那么您会删除哪个，实体还是 DTO？
我将删除实体
没有实体的 DDD 毫无意义。阅读它（最好是其中一本书），你就会明白为什么。
这里的实体是没有业务逻辑的业务对象。业务逻辑是独立的。我读过领域驱动设计，我知道你需要实体。但从我的看法来看，我认为在实体中拥有业务逻辑可能会导致问题。例如，让我们将 Student 作为一个实体。现在，如果我想获取学生列表，则该逻辑不能存在于该实体中。因此，我需要在其他地方编写此逻辑，这意味着我需要从其他层从数据库中获取数据。现在学生实体正在访问数据库。
获取学生是 StudentRepository 的工作，它的接口定义在 Domain 层，但实现在 Persistence 层。所有这些都在书中进行了描述。

标签： domain-driven-design

【解决方案1】：

我真的有必要拥有单独的 BO 和 DTO。

有必要吗？不，DDD 警察不会来敲你的门。

但是关注点分离的原则告诉我们应该区别对待。

业务对象是模型的一部分；他们负责确保模型中的数据满足业务不变量。

DTO（或者更准确地说——您的陈述）是 API 的一部分；它们是可以与其他应用程序共享的与语言无关的消息。

这里的一个关键想法是，由于业务对象是模型的一部分，我们希望支持积极地更改它们以满足业务需求。但 API 并非如此，我们需要稳定性，这样我们就不需要在每次优化业务模型时都重写客户端代码。

另一个观点是，您的表示应该跨越信任边界，您的业务对象用于执行它。 Andreas Hallberg 对此进行了很好的讨论 (slides)

但在这种情况下，我看到有一个没有逻辑的业务对象

这听起来很像您落入anemic domain model 的陷阱。我建议您再次查看您的材料；如果您担心模型中有太多实体与数据库通信，那么您在某处丢失了情节：域模型根本不与数据库通信。

【讨论】：

好吧，据我了解，领域层应该有所有不需要数据库调用但可以在应用层发生的操作。在我当前的应用程序中，我没有很多业务规则和很少的验证。该应用程序更像是一个应用程序，它维护任务队列并在任务完成后更新任务数据。提交数据时有一些验证，仅此而已。
所以在这种情况下，我将向域对象添加验证，所有数据库调用都将从服务进行，并且将在服务中创建域对象以确保数据完整性。然而，一个问题仍然存在，我计划以 json/xml 格式发送所有数据。在这种情况下，我需要 DTO 还是可以简单地将域对象转换为 json/xml。解析器会忽略业务逻辑方法，只专注于 getter，使其成为一种 DTO。这种方法好吗？