2.2 把DDD战略应用到数据

尽管我们在处理操作型系统时采纳了面向领域的分解和所有权，但是基于业务领域的分解思想还没有渗透到分析型数据空间。

到目前为止，在数据平台架构中，我见过的最接近DDD的应用是把操作型系统作为数据源，生成业务领域事件（https://oreil.ly/9ENd4），以便让单体数据平台摄取它们。然而，在数据摄取之后，领域团队的责任即刻中止，数据责任转移到了数据团队。随着数据团队执行更多的转换，数据越来越远离其原始的形式、语言和意图。比如Daff的播客领域在短期保留日志中生成了播放中的播客的日志。然后下游的中心化数据团队收集到这些事件，试图将其转换、聚合并存储为长期存在的文件或数据库表。

为了把DDD应用到数据中，我建议回到最原始的出处。Eric Evans在他的书中引入了一组互补的策略来扩展企业级的建模，称为DDD策略设计。这些策略是为那些有复杂领域和很多团队的组织设计的。DDD的策略设计技术摆脱了以前使用的建模和所有权模式。

组织级别的中央建模

Eric Evans观察到将组织的众多领域模型完全统一既不可行也不划算。这类似于数据建模中的数据仓库，具有紧密依赖的共享模式。集中式的建模会成为组织变更的瓶颈。

孤岛式的内部模型难以集成

这个模式引入了烦琐的团队间通信。这类似于不同应用程序中的数据竖井，通过脆弱的提取、转换和加载过程连接。

缺乏有目的性的建模

这与数据湖类似，只是将原始数据转储到块存储中。

与之相反，DDD的战略设计拥抱了基于“把每个模型置于特定的领域上下文”的建模方法，这个特定的领域称为“限界上下文”（https://oreil.ly/2RhbM）。

Eric Evans在Domain-Driven Design一书中称：“限界上下文是特定模型的限定适用性，它使团队成员对什么必须是一致的，以及什么可以独立开发有一个清晰和共同的理解”。

除此之外，DDD引入了“上下文映射”，它明确地定义了不同限界上下文和独立模型之间的关系。

Data Mesh针对独立的数据产品（数据，以及它的模型与所有权）采纳了限界上下文的边界。

对于那些已经采纳了微服务或者面向领域的架构的组织来说，这是一个相对简单的扩展。它们已经基于领域限界上下文构建了服务。现在，它们把相同的分解和建模方式应用到每个领域中的分析型数据。

领域数据所有权是当今企业复杂系统规模化的基础。

我们把它放在Daff的例子中。媒体播放器团队负责移动和Web的数字媒体播放器。媒体播放器应用生成播放事件，以表示听众与播放器的交互。这个数据被用于许多下游用例，包括改善播放器应用的性能，通过重建和分析听众会话提高用户参与度，探索和聆听音乐的纵长旅程。

在实现Data Mesh之前，无论播放事件从播放设备到达时的质量和节奏如何，媒体播放器团队基本上都把它们丢到了在某种短保留时间的流媒体基础设施上，更糟糕的情况下，会丢到事务数据库中。然后，这些事件由中心化的数据团队收集并放入数据湖或数据仓库，也可能同时放入两者之中。

Data Mesh改变了媒体播放器领域的行为。它扩展了媒体播放器团队的责任，使之提供播放事件的高质量和长保留时间的分析视图——包括实时和聚合视图。媒体播放团队现在已经有了端到端的责任，把播放事件分析型数据直接共享给数据分析师、数据科学家，以及其他对这些数据有兴趣的人。之后，播放事件分析型数据被听众会话领域转换，聚合为基于旅程的听众交互的视图。

推荐领域使用听众会话创建新的数据集——基于听众在社交网络的播放行为推荐音乐的图。

在这个例子中，听众会话领域是一个纯粹的数据领域，其唯一目标是在与播放器交互时提供听众旅程的最佳表示，并添加有关听众资料的独特信息。在这种情况下，对这些数据的需求已经改变了组织。它创造了一个新的领域和一个新的长期团队。图2-1展现了这个例子。