这是《领域驱动设计#1 Advent Calendar 2019》第23篇文章。

晚上好，我是 crossroad0201，目前在工作中负责 splunk> 的运维工作。
在本文中，我想介绍一些在领域驱动设计（以下简称DDD）的背景下，如何利用 splunk> 的想法和思考。

我要分享一个想法，虽然内容并不是很了不起… （笑）

splunk是什么？

大家好，你们知道splunk吗？

一句话来说，它就像Elasticsearch一样，可以存储大量的数据，并使用自己的查询语言进行过滤、各种统计和数据分析，包括图形化等功能。

粉色似乎是企业的代表色，无论是网站还是公开展示的幻灯片，到处都是粉色（笑）。

SPL（Search Processing Language）被称为查询语言，可以使用，并具有从各种数据源导入数据的机制，可以自动解析和索引化数据结构，提供构建和运营大规模集群的机制等特点。
它通常用于集中化和可视化各种操作系统、中间件和应用程序的日志。

在我自己从事业务之前，实际上完全不知道，但它被广泛引入到国内外的大型企业等中，包括在美国举办的.conf大规模活动，以及国内的GOJAS（Go Japan Splunk User Group）等社群活动也非常活跃。

如果您观看这个演示，您就可以了解Splunk是什么样的。

在DDD上使用splunk>

嗯，那么，作为一个热衷于DDD的人来说，我想努力将splunk>与DDD相关联并加以利用…所以，我在考虑将领域事件输入splunk>并进行可视化，觉得这样可能会很有趣。

只是想着如果可以就好了，但实际上没有实践过，所以请谅解…（笑）

域名事件

「领域事件」在弗农的《实践领域驱动设计》一书中有详细解释，所以我认为很多人都知道它，它是对领域内发生的事件进行建模的概念。

比如…

• 新規会員が入会した

• 注文を受け付けた

商品を出荷した

在领域上下文中以过去时态表达的知识会成为领域事件的候选。

微服务和领域事件

当选择采用微服务架构时，领域事件变得非常重要。

正如书籍《微服务架构》等所述，微服务之间的协作可以分为1.请求-响应型和2.事件型。为了实现微服务之间的松耦合和独立性的提高，选择2.事件型的协作是更理想的选项。（请参考这篇文章）

如果采用DDD，可以使用领域事件作为微服务之间进行交互的事件。

在这里让人困扰的是，难以以统一的视角来看待跨微服务之间的事件交互。

将域事件可视化

这里是Splunk>的出现。(嗯，Elasticsearch也可以。)

只要将从各个微服务产生的事件存储到 splunk> 中，就可以使用查询语言SPL轻松查看诸如“订单号 XXXXX 的订单是何时由谁以何种方式处理的”之类的信息。

此外，可能可以通过调查事件发生的日期和时间来分析用户的行为趋势，或者通过观察事件之间的时间间隔来确定业务中的瓶颈，

我认为Splunk的查询语言可以使任何非工程师的人都能够处理（尽管需要学习），以便任何人都可以获得改进业务的反馈意见。

建筑设计

实现的架构非常简单（应该如此）。

如果你正在使用AWS，并且使用Kinesis Streams来发送和接收微服务之间的事件，那么你只需创建一个订阅该流并将数据投入到splunk>的Lambda函数。
由于存在名为HEC（HTTP事件收集器）的机制，可以通过HTTP将数据从Lambda函数投入splunk>，所以使用这个机制可能更好。

另外，Splunk>还有一个来自Kafka导入数据的插件，所以如果您正在使用Kafka进行事件传播，可能也可以使用该插件。

最后
(paraphrased native Chinese translation of “おわりに”)

所以，虽然这篇文章比较简单，但在DDD领域，我认为这些内容并没有被广泛讨论，希望它能成为某种启示。