domain-driven-design - 在新项目中考虑Axon

Question

我将在几个月内开始一个未开发的项目。
该项目将包含许多业务逻辑，分布在多个subdomains上。是的，我们将使用Domain Driven Design原则。
技术将由Spring, Spring Boot & Hibernate堆栈组成。

我一直在寻找一些Java库来覆盖基础设施，例如：


domain event publication
event store
event deduplication
消费者方面的resequencers
projections
reliable publishing
reliable delivery & redelivery
...


我遇到了Axon Framework。我已经听说过，不知道详细信息。因此，我阅读了一些博客文章，少量文档，并观看了YouTube上的一些广播。

似乎很有希望，我正在考虑使用它，因为我不想在基础设施方面一再重复发明。
因此，我正在寻找可以回答和澄清我问题的人：


命令处理

Axon将CommandHandlers与void方法一起使用。是否可以使它们返回值（例如，生成的业务ID）或对象以用于与业务操作有关的通知目的？对我来说，方法将是对此进行I / O阻塞不是问题。



本地与远程域事件发布

我想明确区分local vs remote域事件。
Local domain事件仅应可见并被本地子域使用。是否可以配置事件消耗同步和/或异步？
我的本地域事件可以是“肥胖”。它们被允许携带更多数据，因为它不会跨越域边界。

Remote domain events将是“瘦”的，因此只有远程域所需的最少数据。这种类型的op事件始终需要进行异步处理。

是否可以将本地（胖）域事件转换为域边缘的远程（瘦）域事件？所谓“边缘”，是指基础设施方面。
这样，域模型无需知道本地和远程域事件之间的区别。



同步CQRS

我的应用程序将包含1个（也许2个）core domains和several subdomains。有些域包含很多业务逻辑，因此需要CQRS。
其他领域将更加“粗糙”风格。
是否可以同步执行CQRS？我想以这种方式开始，然后再添加诸如异步处理之类的技术复杂性。用Axon这样可印吗？
这也意味着域事件将在不使用event sourcing的情况下存储在事件存储中。可以在没有事件来源的情况下使用Axon的event store吗？
投影内容也一样，我只想投影域事件以构建读取模型。



模块化整体式

我们将使用modular monolith。
如今，所有microservices内容都不是很时尚。虽然，我深信在每个领域都完全分开的整体应用程序（应用程序代码和数据库架构）中，将以最终的一致性处理操作，并且领域事件包含必要的数据。
以后，如有必要，将更容易迁移到microservices architecture。
Axon是适合模块化整体架构的框架吗？有什么要考虑的吗？



完全分离的域模型（与持久性无关）

域模型将与数据模型完全分离。
我们需要有一个存储库，可以读取数据模型（使用Hibernate）并在需要加载时使用data mapper创建聚合。
还需要另一种方法，需要将聚合转换并保存到数据模型中（使用数据映射器）。
此外，聚合的域事件需要存储到事件存储中，并发布到本地或远程事件处理程序。

这会产生一些后果：


我们需要完全控制与一个或多个DAO（Spring数据存储库）进行通信的存储库实现，以从Hibernate实体中提取必要的数据并与之建立聚合。毕竟，聚合可以在2个甚至3个关系表中建模。
我们在域模型中不需要任何Hibernate注释


Axon是否可以使用这种方法？我仅看到使用直接JPA（将领域模型从1映射到实体的映射）或事件源的示例。
这种方法对我们来说确实是一个大问题，与直接将其映射到数据实体相比，分离的域模型提供了更多的可能性。

下面是我要实现的示例：

在某些域模型包中聚合（不使用JPA）：

public class ScoringResultAggregate {
  // members, constructor, operation omitted for brevity
}

一些基础结构软件包中的休眠实体：

@Entity
@Table(name ="SOME_TABLE_NAME)
public class ScoringResultEntity {
  // member and getters & setters; no domain logic
}

属于域模型的存储库接口：

public interface ScoringResultRepository {
  void save(ScoringResultAggregate scoringResultAggregate);

  ScoringResultAggregate findByApplicationNumber(ApplicationNumber applicationNumber);
}

实现存储库接口的适配器；负责从/向数据映射聚合（JPA）模型：

class ScoringResultAdapterRepository implements ScoringResultRepository {
  private ScoringResultJpaRepository scoringResultJpaRepository;

  ScoringResultJPARepository(ScoringResultJpaRepository scoringResultJpaRepository) {
    this.scoringResultJpaRepository= scoringResultJpaRepository;

  public void save(ScoringResultAggregate scoringResultAggregate) {
    // converts aggregate to ScoringResultEntity and saves the state into DB
  }

  public ScoringResultAggregate findByApplicationNumber(ApplicationNumber applicationNumber) {
    // loads an ScoringResultEntity from DB and converts it into an aggregate
  }
}

轴突服务器

Axon server看起来很有希望。虽然，它仅对 event sourcing有用吗？
它可以与存储聚集（状态持久性）并且域事件在Axon Server中持久化的Sql DB一起使用吗？


很多问题。希望有Axon经验的人可以帮助我:-)

Answer 1

我觉得贾斯珀说的是对的话，但我也想强调一点：


命令处理-是的，您可以在命令处理程序上获得返回值。请注意，不要滥用此功能将的状态返回给用户，因为这会将命令模型（您的聚合处理命令）与查询模型混合在一起。
本地与远程域事件发布-Jasper明确指出了这一点，他是正确的。您渴望形成Axon Server（Enterprise）支持的有界上下文。如果您不使用Axon，则必须自己构建此基础结构。
同步CQRS-Axon很好地提供了异步和同步消息传递的句柄。主要区别在于，您将阻止发送消息的结果。例如，CommandGateway具有send和sendAndWait方法，从而为您提供同步和异步命令分派。最后，在不进行事件搜索的情况下，将Axon Server用作事件存储是完全可以的。使用Axon时，事件来源是一个选择，而不是必须的。
模块化整体-作为公司的AxonIQ积极鼓励采用这种方法来构建软件。所以是的，您可以执行此操作，不可以，在执行此操作之前，我无法想到您应该考虑的任何内容。
完全分离的域模型（与持久性无关）-从查询模型中，您可以完全控制要如何将数据模型与实际使用的模型进行映射。应该将Axon术语中的“聚合”视为您的命令模型，您可以选择“事件源”存储方法或“状态存储”存储方法。 Axon Framework提供的状态存储实现基于JPA，因此需要您在Command Model中的axon注释旁边设置一些注释。如果需要将其分开，我可以想象您将创建自己的Repository和AggregateFactory变体。再说一次，事件搜索方法将使您的域模型完全摆脱持久性注释，因此我会坦白地说。
Axon Server-是的，即使您使用状态存储方法进行聚合，也可以使用Axon Server。知道Axon Server不仅是事件存储，还是命令，事件和查询的统一路由解决方案。如果您要从模块化的整体服务转移到（微）服务设置，那么拥有Axon Server来执行所有消息路由将使您的生活变得非常非常轻松。