数据即服务：领域驱动设计

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

在组织中，处理数据时，我们通常将每个新请求视为一个新的数据指针，并以独立的方式将其暴露给可视化层。大多数情况下这不会有问题，但是，当组织规模扩大时会发生什么呢？问题会开始浮现并引发各种问题。资源将不足以支持提取更大的数据块，不同数据提取或仪表板之间的数据一致性也会受到影响。查询性能的必然下降和计算成本的增加是可以避免的，所以让我们来探讨一下如何避免这些问题。

这类问题需要回顾思考如何利用现有资源，并将数据模型或领域驱动设计与数据模型紧密结合。为了更好地理解如何做到这一点，我们首先来看看领域驱动设计究竟是什么。领域驱动设计中的“领域”指的是“应用程序逻辑围绕其展开的知识和活动范围”。换句话说，“领域”通常指的是软件领域中的“业务逻辑”。在领域驱动设计中，业务逻辑被认为是软件的核心。

例如，在投资银行领域，交易结算是一个关键指标领域，结算比率、结算风险敞口等指标会根据资产类型或账户类型等进行细分。将结算视为一个独立的领域是实现技术采纳并根据需求或过往查询预测未来需求的关键。
一旦深入了解该领域，我们就可以将功能需求与高效、可扩展的数据模型联系起来，从而以一致且最佳的抽象方式满足所有数据请求。这有助于用户思考功能需求，而技术人员则可以构建可扩展的模型作为数据存储库。

一旦领域和模型构建完成，无论需求如何，我们都应该调用一个查询，并根据不同的筛选条件或维度来处理实时或批量请求。在这个阶段，所有抽象数据模型都需要以服务/API（REST/SOAP）的形式公开，以便不仅可以用于可视化或数据库，还可以用于更广泛的用途。这种公开数据的过程使数据得以广泛应用，而其核心是高效的领域驱动设计和数据模型。

构建 API/服务的一些思路是：从数据库入手，将查询作为 NoSQL 目录中的集合作为配置来映射服务，使用 DAO 将服务映射到 API，使用 ElastiCache 来加快服务速度，使用 Flask、Angular 和 Python 来开发 API 和 UI。

总之，始终要从业务角度出发，将请求整合为一个领域，将其构建成一个模型，并在服务方法中作为批处理或 API 提供服务。