Domain driven design 外部数据映射到域

Domain driven design 外部数据映射到域,domain-driven-design,Domain Driven Design,我觉得我指的是上下文映射和反腐败层的DDD主题,但我不确定如何解决它 如何从外部数据源构造/映射域对象 例如,可能有多个数据源、数据库、文件和外部服务。由于我试图构建尽可能类似于洋葱的体系结构,这意味着我的域没有依赖性。基础设施具体取决于域,基础设施实现域接口 如果基础架构必须依赖于域而不是域,那么这是否意味着外部数据映射应该在存储库中完成 若通过构造函数创建对象被视为业务逻辑,不应该泄漏到域之外的任何地方,那个么如何将外部数据映射到域对象?反射其他方式?也许我误解了整个概念 如果域对象创建需要

我觉得我指的是上下文映射和反腐败层的DDD主题,但我不确定如何解决它

如何从外部数据源构造/映射域对象

例如,可能有多个数据源、数据库、文件和外部服务。由于我试图构建尽可能类似于洋葱的体系结构,这意味着我的域没有依赖性。基础设施具体取决于域,基础设施实现域接口

如果基础架构必须依赖于域而不是域,那么这是否意味着外部数据映射应该在存储库中完成

若通过构造函数创建对象被视为业务逻辑,不应该泄漏到域之外的任何地方,那个么如何将外部数据映射到域对象?反射其他方式?也许我误解了整个概念

如果域对象创建需要来自多个源服务、文件、数据库的数据,这是否意味着应用程序服务和基础结构存储库之间应该有一个单独的层来从多个存储库提取数据,所有映射是否都会返回生成的域对象

如何从外部数据源构造/映射域对象

我知道有两种方法

最常见的是,应用程序通过对值的共同理解与域模型进行通信。应用程序采用它的表示形式(例如,文件中的字节),并从中构建域模型将理解的表示形式。您可以通过了解如何将原语值转换为值类型或生成器的工厂看到这一点

更罕见的方法是应用程序采用它所拥有的表示,并将其封装在域模型将识别的适配器中,而不是构建具体类型。在这种样式中,值类型看起来更像角色接口,使域模型忽略底层数据模型

如果域对象创建需要来自多个源服务、文件、数据库的数据,这是否意味着应用程序服务和基础结构存储库之间应该有一个单独的层来从多个存储库提取数据,所有映射是否都会返回生成的域对象

我希望存储库能够自己完成这项工作——存储库的角色是对键值存储的抽象

我们建议从一系列困难的设计决策或可能发生变化的设计决策开始。然后,每个模块都被设计成对其他模块隐藏这样的决策


服务/文件/db的选择是一个应该隐藏在模块中的决策的例子。选择存储库的接口是为了尽可能少地揭示其内部工作。

我更喜欢通过反腐败层的显式实现来实现这一点。我的域通常接受命令来执行任何操作,这是域模型可以接受的。这包括创建对象和执行状态转换

ACL部件从外部数据源读取数据,或通过任何其他方式从外部数据源接收数据。然后将该数据转换为有效的域命令。所有预检查都是通过ACL完成的,ACL了解外部数据格式和域

有时,一个外部事件会导致域中的多个操作,甚至跨多个有界上下文的多个操作。通常这是通过使用流程管理器来完成的

正如您所描述的,可能需要多个外部数据源作为查询来构造一个有效的域命令。在本例中,ACL只是这样做,因为域中只有一个事务。当外部源还需要获得某种确认时,它可能会变得更加复杂,process manager也可以用于此目的