作者回复: 1. CAP是实现了outbox的机制，也就是本地事件表的机制，可以参考：https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/subscribe-events#designing-atomicity-and-resiliency-when-publishing-to-the-event-bus 2.这里是提供了最复杂情况的示例，在不需event bus的服务，可以使用seedwork的模式来复用代码，也可以为其设计一个独立的共享包 3.跨服务的情况，即一个服务负责发布事件，一个服务负责订阅，示例中发布和订阅写在了同一个微服务周中，实际场景是在不同服务的。 4.serilog支持更多的日志输出，例如fluentd、elasticsearch，当然nlog和log4net也不错，选择哪一个与你的熟悉程度也是有关系的，满足诉求即可。 5.后面我尝试补充一下相关内容。 5.

作者回复: 领域事件是由领域模型驱动触发的，应该与领域模型放在一起。 对于领域事件的处理，你可以理解成一个由事件发起处理命令，这个命令与用户从API发起命令实质是一样的，因此事件处理handler应该在应用层，它需要通过发起用各种Command来实现事件的处理。

作者回复: 集成事件是相对于领域事件而言，领域事件是指领域模型触发的事件，集成事件是将这些事件在不同的微服务之间传递的手段，集成事件的触发，一般也是由领域事件驱动的。

作者回复: 建议将事件定义为幂等的，避免依赖顺序。

作者回复: 集成事件用来跨微服务传递领域事件的

作者回复: 这种情况还是拷贝一下好，因为两端的更新有可能无法做到同时更新。 新版本发布时，考虑兼容即可

作者回复: 是的，集成事件的作用就是跨微服务传递事件

作者回复: 对的，集成事件是为了在微服务之间传递事件。 发布者将事件定义到一个公共类库是可行的。 不过一般，每个服务关注的事件都是不一样的，引入这个类库并没有带来非常大的收益，这个取舍可以看团队的习惯，以及事件共享库的更新频率

作者回复: 事件表示领域模型发生了什么，是客观存在的，是否发送是由是否有人关心它决定的，应用层可以决定是否接收，而不是是否发送。 另外，当一个事件没有任何业务关心，则可以不定义它。

作者回复: 领域层不应该关心其是如何存储的，不建议把仓储与领域模型放在一层