2

每当我查看Axon Bank时，我开始想知道我是否应该遵循一组事件和命令的设计规则。

在 Axon Bank 中，事件和命令都完全由原语组成。在我的应用程序中，我倾向于尽可能避免使用原始用法，主要是为了构建一个富有表现力的域并在我能得到它的任何地方都具有类型安全性。

Axon 本身带有一些 DDD 引用，但无论我浏览哪些文档，没有一个示例使用复合对象作为事件/命令有效负载的一部分。

这让我很困惑。内置对完整的 xml 和 json 序列化的支持，而不仅仅是拥有一些键值对。

我知道，特别是事件往往是小而简单的结构，因为它们只反映增量状态变化，但复杂的域模型和事件（条目）之间总会存在某种差距。

在我的域中，我可以有一堆类，如OverdraftLimit,和.CurrentBalanceDepositAccountIdentifier

现在有两种可能的方式来设计事件和命令：

1. 基元和广泛转换

  • 将事件视为带有漂亮标签的原始数据
  • 一旦原始数据“进入”应用程序，就将其转换为强大的对象

  • 创建事件时，只需再次剥离它们。

    public class BankAccountcreatedEvent {
    private final String accountIdentifier;
    private final int overdraftLimt;

    // ...
}

    在其他地方：

    public void on (BankAccountCreatedEvent event) {
    this.accountIdentifier = AccountIentifier.fromString(event.getAccountIdentifier());
    this.overdraftLimit = new OverdraftLimit(event.getOverdraftLimit());
}

优点：

  • 没有任何奇怪依赖的简单命令/事件 API
  • 使分发更容易
  • 仅当实际事件结构发生变化时才需要向上转换者，因此可以轻松预测。

缺点：

  • 需要编写和维护一个巨大的转换层
  • 主要出于技术原因将事件/命令和域模型的其余部分解耦引入了一个新的、人为的、上下文的差距

2. 富有表现力的有效载荷

  • 直接使用复杂类型作为属性

    public class BankAccountCreatedEvent {
    private final BankAccountIdentifier bankAccountIdentifier;
    private final OverdraftLimit overdraftLimit;

    //..
}

优点：

  • 少写，更容易阅读
  • 把自然属于一起的东西放在一起

缺点：

  • 领域逻辑间接影响事件结构，向上转型将需要更频繁且更难以预测。

我需要第二个意见。有推荐的方法吗？

4

1 回答 1

1

首先要记住的是，事件的序列化形式是您的正式合同。最后，如何在 Java 类中表示这一点取决于每个应用程序。例如，如果您将序列化程序配置为忽略未知字段，则可以将不关心的字段留在外面。

就个人而言，我不介意事件中的原语。但是，我确实理解对某些字段使用显式值对象的价值，因为它们允许您表达每个字段所涉及的“数学”。在标识符的情况下，它们可以防止“混淆”，其中标识符被用于意外地尝试识别另一种类型的对象。

最后，这并不重要。通过一些简单的 Jackson 注释，您可以将这些值对象转换为 JSON 中的简单值。例如，查看@JsonValue。

public class BankAccountCreatedEvent {
    private final BankAccountIdentifier bankAccountIdentifier;
    private final OverdraftLimit overdraftLimit;

    //..
}

将映射到：

{
    "bankAccountIdentifier": "abcdef1234",
    "overdraftLimit" : 1000
}

如果 BankAccountIdentifier 和 OverdraftLimit 类都有一个 @JsonValue 注释方法，该方法将返回它们的“简单”值。

于 2017-06-07T14:44:16.050 回答