【问题标题】:Domain Events - Inheritance or use of enums领域事件 - 枚举的继承或使用
【发布时间】:2017-02-14 15:58:07
【问题描述】:

所以猜猜我有这种领域事件:

class BookChangedName...
class BookType1ChangedName extends BookChangedName...
class BookType2ChangedName extends BookChangedName...

这样更好还是:

class BookChangedName{
    enum bookType = BOOK_TYPE_1;
}

因为他们说只有在类之间存在不同的行为时才使用继承,所以我假设在这里我会使用枚举示例(案例 #2)——因为域事件只是简单的 DTO。

但同样,在我的领域中,这种不同类型的事件具有不同的含义(不同的处理路径)。因此,如果我使用示例 #1,我最终会得到很多:

if(event instanceof BookType1ChangedName){
   //do smth in domain
}
else if(event instanceof BookType2ChangedName){
   //do smth in domain
}

而且我也不能这么明确:

when(BookType1ChangedName event){...

我必须做一些预处理,比如:

@EventHandler(matcher_pattern = event->event.bookType==BOOK_TYPE_1)
when(BookChangedNameevent){...

【问题讨论】:

  • 如果您的 booktypes 是不同的聚合,如果您使用继承可能是单亲,您可以使用相同的事件并在基类中有处理程序。

标签: event-handling domain-driven-design event-sourcing domain-events


【解决方案1】:

您的领域专家是否使用短语“BookType1”?您说每种书籍类型都有不同的逻辑路径-我建议为此询问理性,也许每个事件都有一个更面向领域的名称?试着听听领域专家用来描述这两种情况的语言。

如果你能找到更多描述性的语言,我会选择基于继承的单独事件。借助某些领域事件机制,您可以订阅处理抽象超类或任一专业化,如果您想要这种灵活性,这可能会有所帮助。

另一方面,如果它真的只是 booktype1 和 booktype2 并且将来可能是 booktype3 和 booktype4,我会考虑一个枚举甚至只是一个整数,并考虑在不同的 策略中实现不同的逻辑路径 并让您的域事件处理程序使用 工厂 为给定的书籍类型返回适当的策略,然后委托给该策略以执行逻辑。

【讨论】:

    【解决方案2】:

    事件名称是 DDD 中的重要组成部分(实际上任何“名称”都很重要),因此我建议为不同的事件使用不同的事件名称,因为这些名称包含大量信息。此外,如果您使用类型代码(带有enum),您会增加CRAP 索引,因为额外的ifs。

    【讨论】:

      【解决方案3】:

      您应该只拥有一个 BookChangedName 事件并拥有该事件的 BookType 属性。事件的处理程序/订阅者应该负责逻辑。

      【讨论】:

      • 这句话背后的原因是什么?
      • 它们是类似的事件 BookChangedName、BookType1ChangedName、BookType2ChangedName 等。不必为每种书籍类型创建不同的事件类,只需让事件的处理程序实现每种书籍类型的处理方式即可。处理程序可以使用策略模式,因此它不必处理 if/else 语句。
      猜你喜欢
      • 2011-03-07
      • 2010-10-19
      • 1970-01-01
      • 2016-01-16
      相关资源
      最近更新 更多