
通信和数据契约
|
37
数据。这个输出事件必须被视为唯一的事实来源,并且必须被记录为一个不可变的事实,
以供下游消费者消费。关于实际发生的事情,它是完全且权威的信息来源,消费者不需要
查阅任何其他数据源就知道发生了这样的事件。
3.3.2
每个流都使用单一事件定义
事件流应该包含表示单一逻辑事件的事件。不建议在一个事件流中混合不同类型的事件,
因为这样做会混淆事件的定义和流代表的含义。在这种场景中,由于可能会动态地添加新
schema
,因此很难对正在生成的事件进行
schema
验证
。尽管在某些特殊情况下,你可能
希望忽略这一原则,但是在系统架构中生产和消费的绝大多数事件流应该有严格、单一的
定义。
3.3.3
使用最窄的数据类型
为事件数据选用最窄的类型。这可以让你依赖代码生成器、语言类型检查(如果支持的
话)和序列化单元测试来检查数据边界。听起来很简单,但在很多情况下,当你使用不正
确的类型时,歧义就会慢慢出现。以下是一些很容易避免的实际例子。
使用字符串类型来存储数值
这需要消费者解析字符串并将其转换成数值,并且通常会出现像
GPS
坐标那样的奇怪
数值。这很容易出错,特别是在发送空值或空字符串时。
将整型作为布尔型使用
虽然
0
和
1
可以分别用来表示假和真,但是
2
表示什么呢?
-1
又表示什么呢?
将字符串类型作为枚举型使用
这对于生产者来说是个问题,因为生产者必须确保发布的值与接收的伪枚举列表匹配。这
不可避免地会出现输入错误和不正确的值。对这个字段感兴趣的消费者需要知道可能的值
的范围,这将需要与生产团队沟通,除非在
schema ...