洋葱架构——我们应该在我们的核心 POJO 中允许 Jackson 注释吗？

Question

我有一个应用程序接收 JSON 消息，然后将其反序列化为 POJO。我已经研究洋葱架构几个星期了，我偶然发现了这种情况的技术困境。由于我使用的是 Jackson Deserializer，因此我被迫使用 Jackson Annotations 来协助反序列化过程。应用程序核心需要这个 Jackson POJO，问题就来了。由于反序列化是一个基础设施问题，因此在我的核心中使用 Jackson 注释类是不正确的，对吗？

我看到 2 个选项：

1 - 我的核心将有一个类似于 Jackson POJO 的 POJO，但没有注释。 Jackson POJO 将位于基础结构中，然后我将使用映射框架将 Jackson POJO 映射到域 POJO。

基础设施层的POJO：

public class MyUser {

    private String firstName;
    private String lastName;

    @JsonProperty("first_name")
    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    @JsonProperty("last_name")
    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

核心层POJO：

public class MyUser {

    private String firstName;
    private String lastName;

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

2 - 假设 Jackson 是横切的，因此可以跨层使用。

考虑到我遵循的是洋葱架构，我认为选项 1 更合适。但是，坚持使用此选项将迫使我复制对象，这对我来说听起来不太好。

真的只有这两个选项吗？有什么建议吗？

Answer 1

您的解决方案之一是众所周知的解决方案 数据传输对象设计模式 或 DTO 如果您想了解更多相关信息。

在我看来，这些不是对象重复。它们是同一领域概念的不同表示，各自适应特定应用层的需要。并且对于每种模式，有时都必须使用它们，有些时候它毫无用处，而且比任何东西都更具破坏性。

我自己的经历：我们有一个项目，我们选择对每一层使用相同的 POJO，以避免重复和必须处理映射。几周后，我们遇到了 cross-concerns 的小问题 "hacked out"。

不久之后，这些问题变得更加严重（性能、API 层中的数据库问题......）并且修复这些问题的技巧最糟糕。最后，在经历了很多令人头疼的事情之后，我们同意映射和 POJO 复制是有意义的。

但也可能发生相反的情况：您可以为一个简单的 CRUD 应用程序使用很少的逻辑进行严格的映射分层。然后严格的分层架构是浪费时间和精力。

答案通常是：这取决于您要构建的内容。应用程序越大越复杂（可扩展性在这里很重要），架构就必须越严格。但是一个简单的应用程序（或更大结构的任何简单节点）需要保持简单。

希望对您有所帮助！

洋葱架构——我们应该在我们的核心 POJO 中允许 Jackson 注释吗？

Onion architecture - Should we allow Jackson annotations in our core POJOs?

jackson

domain-driven-design

separation-of-concerns

onion-architecture