java - DDD - 在拥有映射器类时不暴露 setter/getter

Question

我最近阅读了很多有关 DDD 的内容。我有一些基本知识(并在实践中使用它)但现在我决定(几乎)100% DDD。当然，我马上就遇到了问题。

我为每个模块(功能)分配了 3 层:应用程序、域和基础架构。我使用六边形架构模式，这基本上意味着我在领域类中获得了我的核心逻辑，应用层使用它(但领域层根本不知道应用层)，基础设施从领域(数据库存储库)和一些接口(interface)实现我的端口来自应用层等

现在，当我处理应用程序服务中的一些用例时，我必须使用我的根聚合并执行一些逻辑，最后将它映射到 UI 的某个 DTO。问题是要执行这样的映射，我必须为我的大部分属性提供 getter/setter，这让我很吃力。我想通过提供大量业务方法而只提供很少的 getter/setter 来避免贫血模型。

我可以看到 2 个解决方案:

• 在我的领域层引入 DTO，这又是 DDD，并在我的实体中有方法 toDTO()
• 提供 getter/setter 并仅在映射器中使用

任何其他解决方案，你们如何处理应用程序中的此类常见问题？我知道在现实中很难完全采用 DDD，不遵守所有规则也没关系，但我注意到尽可能少的 getter/setter 对我的设计有很大帮助，但同时很明显 DTO 不属于到域。

Answer 1

The problem is that to perform such mapping I have to provide getters/setter for most of my attributes which kills me.

是的 - 我为此奋斗了很长时间。真正的答案是没有魔法。

如果您希望聚合有用，您需要能够以某种方式从中获取信息。只写数据库不是很有趣；如果没有 query在界面上可用，那么首先将信息放入其中就没有太多意义了。

从聚合中获取值 的域特定查询是可以接受的。关键限制

1. 应该不可能通过操纵返回值来改变聚合的状态。因此，我们倾向于返回没有修改器的对象或这些对象的副本。

2. 我们不应该鼓励消费者查询我们、对查询结果执行一些操作，然后根据这些操作的结果选择命令的习语。

   //不要这样做:int x = o.X();x = x + 1;o.Y(x)

您可以做一些事情，使代码整体看起来“更干净”。

1) 让聚合响应具有值对象的查询，然后查询这些值对象以获取构建 DTO 所需的信息。

2) 将工厂方法传递到聚合中以获取您需要的数据

<T> T query(API<T> api)

在哪里API<T>是聚合可以与之交互的构建器/工厂事物。

3) 聚合实现了两个独立的接口(interface)(一个用于查询，一个用于命令)，并且只允许调用者访问他们需要的接口(interface)。

4) 使用单个查询点从聚合中获取“当前状态”，然后从中构建其他所有内容。