Domain driven design 对于DDD，实体和DTO始终是强制性的吗

我是领域驱动设计的新手。目前我有大约5个bean，它们之间有一个层次结构。严格来说，这些豆子是DTO。但是，我会将它们从域层返回到服务层和控制器。这对我来说很好，但是根据域驱动设计，域层必须返回BO，服务必须返回DTO或BO，控制器将映射到DTO。我不明白这有什么意义，因为最后我将把服务返回的对象转换为JSON，JSON只是数据。所以，我真的需要有单独的BOs和DTO吗

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

我真的有必要将BOs和DTO分开吗

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

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

业务对象是模型的一部分；他们负责确保模型中的数据满足业务需求

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

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

另一个观点是，您的表示应该跨越信任边界，在信任边界中，您的业务对象被用来强制执行它。安德烈亚斯·哈尔伯格对此进行了很好的讨论

但在本例中，我看到了一个没有逻辑的业务对象

---

这听起来很像你掉进了一个陷阱。我建议你再复习一遍你的材料；如果您担心模型中有太多的实体与数据库通信，那么您已经在某个地方丢失了绘图：域模型根本不与数据库通信。

那么您将删除哪个实体或DTO？我将删除实体DDD而不删除实体毫无意义。仔细阅读（最好是其中一本书），你就会明白为什么。这里的实体是没有业务逻辑的业务对象。业务逻辑是独立的。我读过领域驱动设计，我知道你需要实体。但从我的角度来看，我认为在一个实体中拥有业务逻辑可能会导致问题。例如，让我们将学生作为一个实体。现在，如果我想得到一个学生列表，这个逻辑不能存在于这个实体中。因此，我需要在其他地方编写这个逻辑，这意味着从其他层我需要从数据库获取数据。现在学生实体正在访问数据库。获取学生是StudentRepository的工作，其接口在域层定义，但在持久层实现。所有这些在书中都有描述。好的，据我所知，域层应该有所有不需要数据库调用但可以在应用层发生的操作。在我当前的应用程序中，我没有太多的业务规则和很少的验证。此应用程序更像是一个维护任务队列并在任务完成后更新任务数据的应用程序。提交数据时会进行一些验证，但仅此而已。因此，在本例中，我将向域对象添加验证，所有DB调用都将从服务中进行，并在服务中创建域对象以确保数据完整性。不过还有一个问题，我计划以json/xml格式发送所有数据。在这种情况下，我需要DTO还是可以简单地将域对象转换为json/xml。解析器将忽略业务逻辑方法，只关注getter，使其成为DTO。这种方法行吗？