数据驱动设计中的领域数据存储与最佳实践

### 数据驱动设计中的领域数据存储与最佳实践 #### 1. 共享内核与DDS边界划分 在数据驱动设计里，共享内核指的是部分领域模型在不同团队或子领域间共享。这种共享内核的集成策略能够减少重复工作与额外开销。 为避免领域数据存储（DDS）过多或过少，需明确设定DDS的边界，让每个用例或一组用例仅消费和集成所需的数据。确定逻辑DDS边界的合适范围、大小和位置颇具难度，在跨领域分配数据时会带来挑战。通常，有界上下文以主题为导向，与业务能力和价值流相契合。理想情况下，领域和DDS的边界应保持一致，但实际并非总是如此。例如，一个非常大的DDS可能用于多个用例（即多个领域），或者一个大领域可能包含多个用于该领域不同用例的DDS。 在定义领域的逻辑边界时，可以将子领域组合成一个更大的领域，再分解DDS设计，以简化数据建模活动和更大范围内的内部数据分配。比如，若一个价值流边界内的多个领域紧密协作，可在DDS架构边界内将它们逻辑上整合在一起。对于需要数据保持一致的用例，同样适用此原则。在可能的情况下分解领域也很重要，特别是当领域较大或子领域需要通用（可重复）的集成逻辑时。此时，创建一个提供集成逻辑的通用子领域，能让其他子领域实现标准化并从中受益。基本原则是保持子领域间的共享模型尽可能小，并始终遵循通用语言。 #### 2. 分析架构设计中的考虑因素 设计分析架构时，要仔细思考DDS的逻辑角色，这涉及业务和技术粒度两方面的考量： - **业务层面**：从业务关注点的自上而下分解入手，分析最高级别的功能上下文、范围（即边界上下文）和活动。将其划分为更小的功能区域、用例和业务目标。这需要具备良好的业务知识和有效划分业务流程、领域、功能等的专业技能。最佳实践是将业务能力作为参考模型，寻找通用术语（通用语言）和重叠的数据需求，如共享的集成逻辑。 - **技术层面**：考虑技术目标及实现方式，包括可重用性、灵活性（易于适应频繁的功能变化）、性能、安全性和可扩展性等。关键在于做出正确的权衡。例如，两个业务领域可能使用相同的数据，但如果它们的技术要求冲突，最好将问题分开处理。若一个业务任务需要密集聚合数据，而另一个只需快速选择单个记录，即便使用相同的数据，也最好将它们分开。同样，若一个用例需要每天更新数据结构，而另一个期望数据结构至少在一个季度内保持稳定，也应考虑将它们分开。 #### 3. 数据重用与DDS架构 数据重用也是需要考虑的问题。同一集成数据可能用于多个用例。当一个领域较大且由多个（重叠的）子领域组成时，在业务边界内组织数据会变得更加复杂。此时，DDS可能成为不同领域区域的集合，有些区域在多个子领域间共享，而有些区域则专门映射到一个领域。以奖章架构为例，对于一个大领域，可以围绕一个DDS的各个区域划定边界。在这个DDS中，前两个区域（青铜和白银）可在多个子领域间共享，因此诸如数据清理、修正和构建历史数据等任务可由所有子领域共同执行。对于第三个区域（黄金）的转换，情况会更复杂，因为数据需要针对每个子领域或用例进行定制。所以，会有共享的管道和特定于某个用例的管道。整个数据链，包括所有管道，可视为一个大型DDS实现。 分层是数据仓库的核心概念，但DDS在应用分层时，边界更加清晰。在DDS中，并非集成所有数据，而是仅为特定业务目的选择和消费数据。 正确引导消费端是成功实施联邦架构的关键要求之一。若不为领域团队提供架构指导，可能会在多个领域出现重叠和重复的活动，对于数据组合时出现的相同集成挑战，会有不同的解决方案。因此，建议将消费端管理与数据产品和主数据管理活动结合起来。 #### 4. DDS与数据产品的区别与联系 数据产品的目标是提供数据，而DDS的目标是消费数据并将其转化为价值，用于支持诸如报告和机器学习服务等功能的业务决策。DDS消费的数据与数据产品架构通常管理的数据也有所不同。DDS中的数据已针对当前用例进行了结构化和优化。每个业务问题都是独特的，可能涉及不同的目标用户群体、不同的业务需求和不同的非功能需求。 不过，在分发新创建的数据方面，DDS与数据产品可能会有一些重叠。DDS可以充当数据消费者、提供者，有时两者皆是。也就是说，DDS可能会与其他应用共享新创建的洞察和数据。为此，需要仔细考虑如何协调架构的数据提供和消费端。有两种设计模式可供选择： - **模式一**：领域A使用一种架构专门消费和使用数据，另一种用于数据产品开发。 - **模式二**：领域B使用一种组合架构，支持数据价值创造和数据产品开发。 若DDS仅设计用于分析用例的数据消费和使用，则需使用单独的架构来共享新创建的数据（即构建新的数据产品时）。在这种情况下，DDS架构需要一个新的蓝图和一组新的服务。使用两个单独的蓝图管理DDS的动机是将数据使用和共享的问题解耦，使分析用例的内部架构与数据产品创建和共享的架构相隔离。 若DDS设计为包含数据产品架构，则可使用同一架构直接向其他消费者消费和共享新创建的数据。这样设计蓝图，在数据消费和共享所使用的底层服务方面会产生协同效应。例如，可以使用相同的ETL框架或共享计算资源来实现数据消费和共享新创建数据这两个目标。但另一方面，由于两者都在同一架构内管理，识别数据副本和新创建的数据会更加困难，因此存在耦合风险，需要通过使用元模型等方法来缓解。 蓝图设计会受到DDS和数据产品是共同管理还是独立管理的选择的重大影响。此外，蓝图可能因将数据转化为价值所需的活动而有所不同。分析用例是独特的，可能需要不同的服务。例如，仅使用报告服务的用例需要的蓝图与使用机器学习功能的用例不同。 对于DDS内部管理的数据，建议根据一些基本原则区分数据产品数据和集成数据。集成数据是指已被消费、组合并转换到新上下文中的数据。输入和原始数据来自其他地方，因此数据血缘是一个更重要