我们有几个遗留应用程序，主要由gui+服务层+rdm组成。随着时间的推移，添加了一些批处理以在不同的数据库之间同步/传输数据，等等。通常的意大利面结构：）
我们正在清理这个烂摊子，我们正在设计一个基于 event sourcing 以及 materialized views :
基于kafka和kafka流的事件日志
这些事件流式传输到消费应用程序，这些应用程序按自己的方式使用/存储数据
一步一步地，现有的应用程序将不得不采用这种架构。这就是我担心的地方。如何处理数据验证？
对于遗留应用程序，当用户更新ui上的数据时，服务层在将新状态持久化到数据库之前进行验证（技术检查和业务检查）(由 technical checks 我的意思是检查字段的类型，长度，外键的存在，。。。通过 business checks ，例如“如果attr\u a=，那么attr\u b不能为空”
对于新的架构，即使我们承诺依靠 event sourcing 模式，我意识到我现在设计的东西看起来更像一个 CQRS + Event Sourcing 解决方案：

Service layer > Kafka topic "Commands" > Validation > Kafka topic "Events" > Consuming apps

（与 Service layer 在这个设计中，重要的是要记住“生产应用程序”也是一个“消费应用程序”，生产应用程序的数据库只会在循环结束时更新。
我不确定我们的方向是否正确。我预见有2到3种不同的方式可以走得更远。没有一个是100%满意的：
1如果您继续使用此cqrs选项
保留“命令”主题：

Service layer > Kafka topic "Commands" > Validation > Kafka topic "Events" > Consuming apps
<PRODUCING APP> <---------------------- STREAMING PLATFORM ----------------><.CONSUM APP.>

我设计了 Validation 阶段由kafka streams应用程序管理。在这种情况下，处理我之前所说的“技术检查”不会太复杂。但我真的不确定 Streaming Platform 是处理商业支票的正确地点。
2如果继续使用此cqrs选项，则不进行业务验证
保留“命令”主题：

Service layer   >  Kafka topic "Commands" > Kafka topic "Events"   >  Consuming apps
<.PRODUCING APP.> <---------------- STREAMING PLATFORM ------------> <..CONSUM APP..>

我们可能会遇到这样的情况：应用程序可能会生成无效的事件，这些事件甚至无法存储在自己的数据库中(举例来说，一个应用程序可能会推送一个命令，比如“createanewaddress”，其中包含一个在其表“country”中不存在的国家代码。这就像一个悖论：“event”存在，它是一个事实，但它的父级不接受这个事实。
三。如果我们使用Kafka存储“事件”主题，而不是“命令”：
没有“命令”：

Service layer   >  Kafka topic "Events"   >  Consuming apps

这里再次介绍如何避免生成应用程序来发布无效事件。
你有什么建议？
我的设计中有没有遗漏一个概念？
与CQR合作有意义吗？
“流媒体平台”是否应该不执行验证，信任正在生成的应用程序并接受主题中的所有事件？
在发出命令或事件之前，应用程序是否应该根据已经管理的数据验证数据？
当做，