我参加了由吉祥寺.pm组织的2020设计之夜活动。
我有些地方跟不上，没有全部记住，但在我忘记之前，我还是写下来吧。

CQRS+事件溯源

最初是由加藤純先生进行的关于CQRS和Event Sourcing的解说。资料链接如下：

总结起来，内容如下：

• CQRSは境界を引いてCとQを完全に分断しなければならないので、コストがかかる。

 

• Event Sourcing無しでCQRSは難しい。

 

コストをペイできるほどの大規模なものや、耐障害性を求めないならやらないほうがいい。

我之前也经常使用かとじゅん提出的解决方案。虽然以WEB服务为基础，但GET请求必须通过查询参数来改变条件或设置获取数量的上限（如分页），而其他模块只能根据基本固定的条件使用领域逻辑进行数据获取。这样做会给其中一个模块带来负担，所以最好一开始就使用不同的模块进行数据获取。然而，かとじゅん提出的现实解决方案中建议在查询时使用领域层的值对象（VO），而我则完全禁止使用。基本上，我的数据设计是基于不可变数据模型（入门篇，世代边），但我也会为查询准备一些非规范化的表，因为我不希望查询端的命令值对象逻辑产生影响。我也曾经认为这不符合DRY（不重复原则），但我认为这还在可接受范围内。关于事件存储，有几个推荐的选择，包括聊天栏等。

• HBase

 

• Kafka

 

Datomic

如果以后有机会举办活动，我打算参考一下事件策划。

GraphQL 发音为“昆图尔”，是一种用于构建API的查询语言和运行时。

qsonaさん的演讲是关于GraphQL的。资料链接如下：
https://hackmd.io/@jnl1y8gDTkq7ywsLXpa6GQ/HkDGObSOP
由于我对GraphQL在客户端和服务器端的使用都没有经验，所以我对这个主题不是很了解。
不过，由于演讲中提供了具体的实现资料，我觉得下次自己尝试实现一下也不错。
有一种观点认为应该在BFF（Backend For Frontend）中使用GraphQL。但是，也有人认为“BFF是为了满足特定的前端用例而创建的，而GraphQL是为了在各种客户端自由使用而创建的，两者的需求不符合”。我对这个观点表示认同。

总结

因为我喜欢这样的设计讨论，所以我希望能参加更多这样的活动，但是很少有机会。(可能是因为我找不到合适的途径吧)
为了能更好地跟上讨论的步伐，我考虑开始接触一些存储和队列等技术，不仅限于编程语言。