DDD：表示层和领域层类的命名约定答案

【问题标题】：DDD: naming convention for Representation Layer and Domain Layer classesDDD：表示层和领域层类的命名约定
【发布时间】：2015-07-17 02:29:48
【问题描述】：

我提前道歉，因为这个问题几乎有点傻。尽管如此，我自己也想不出一个好的解决方案，所以我觉得还是值得一问的。

当 Representation 对象和 Domain 对象应该具有相同的名称时该怎么办？ DDD Sample 并没有真正解决表示层，所以我无法在那里找到帮助。 Account 类的工作原理与任何说明一样：

package com.mycompany.myproduct.representation;

public class Account {
    private String uuid;
    private String accountNumber;
    // etc

    @JsonCreator
    public Account(@JsonProperty('uuid) String ....
}

也许这个系统有一个约定，尽可能将数据作为字符串返回。但我喜欢在这里拥有所有 Json 注释。虽然这意味着 XML 并没有得到真正的支持，但目前看来还可以，尽管有更大的灵活性会更好。那么在 Domain 层中可能还有另一个类是这样的：

package com.mycompany.myproduct.domain.model;

import java.uti.UUID;

public class Account extends Entity {
    private UUID id;
    private BigDecimal accountNumber;
    // ... business logic, etc
}

如果这两种数据类型的名称相同，则在它们最终必须相遇的情况下，代码将很难看/无法支持。作为通用语言的一部分，域层似乎必须具有帐户类。但外界谈论的是表征对象。如果那是他们的语言，他们为什么要使用不同的语言？

【问题讨论】：

你确定在 DDD 中有一个“表示”层吗？我认为只有接口、应用程序、域和基础设施层（首先遵循分层架构时）。无论如何，在您的情况下，我认为在 Domain 层中只有一个 Account 类，并且该类可以很好地具有 JSON 注释。
我并不是要暗示在 DDD 中正式存在这样一个层 - 这就是我所说的在我包含的 DDD 示例链接中没有解决这样一个层的意思。这并不意味着 REST 表示层不能与 DDD 一起使用。我问的是人们在这种情况下会做什么。
我认为元数据注释（如@JsonCreator）或JPA 的持久性注释（如@Id、@Temporal 等）在应用于域层中的实体时很好。所以，我会使用同一个类。
您使用的是 DTO（数据传输对象），这是一个不错的选择。我倾向于不公开持久层对象。我在 DTO 中看到的一个常见模式是简单地将 DTO 附加到类名。我什至看到有人使用Representation。就个人而言，我通常不使用相同的名称。它变得混乱

标签： java rest domain-driven-design representation

【解决方案1】：

由于这两个类位于不同的命名空间中，您可以保持相同的名称。但正如您所提到的，这可能会变得丑陋，而且肯定会产生误导。

我强烈主张在您的领域层中使用纯粹的“真实世界”命名。帐户就是一个很好的例子。您丰富的Account 域实体及其状态、行为和不变量，代表现实世界中的一个帐户。

在您的域之外命名的标识符可能应该对使用它的上下文更明确。比如我一般使用如下：

AccountModel 用于 API 响应模型。
AccountTable 用于 ORM 类。
AccountDto 用于某些传输对象（尽管请尽量避免 DTO！）

每个人都有自己的标准。我认为保持一致性很重要，尤其是当您与团队合作时。

【讨论】：