外部数据映射到域 [英] External data mapping to domain
问题描述
感觉就像我在指的是上下文映射和反腐败层的DDD主题，但我不确定如何解决它。
It feels like I am referring to DDD topics of context mapping and anticorruption layer, but I am not sure how to address it.
如何构造/映射域来自外部数据源的对象？
How to construct/map domain objects from external data sources?
例如，可能有多个数据源（数据库，文件，外部服务）。由于我正在尝试构建与洋葱体系结构尽可能相似的结构，这意味着我的域没有依赖性。基础架构取决于域（具体来说，基础架构实现域接口）
As an example there could be multiple data sources (db, files, external services). Since I am trying to build as similar to onion architecture as possible it means that my domain has no dependencies. Infrastructure depends on domain (specifically, infrastructure implements domain interfaces)
-
如果基础架构必须依赖域（反之亦然），
If infrastructure has to depend on domain (not vice versa), does it mean that external data mapping should be done within the repository?
如果通过构造函数创建对象被视为业务，如何将外部数据映射到域对象？逻辑（哪个不应该泄漏到域以外的任何地方）？反射？其他方法？也许我对整个概念有误解？
How do you map external data to domain object if creating object via constructor is treated as business logic (which should not leak to anywhere but domain)? Reflection? Other ways? Maybe I am misunderstanding the whole concept?
如果域对象创建需要来自多个源（服务，文件，数据库）的数据，是否意味着应该有在应用程序服务和基础结构（存储库）之间的一个单独的层，它从多个存储库中提取数据，是否进行所有映射并返回结果域对象？
If domain object creation requires data from multiple sources (services, file, db), does it mean that there should be a separate layer between application service and infrastructure (repository) that pulls the data from multiple repositories, does all the mapping and returns resulting domain object?
推荐答案
如何从外部数据源构造/映射域对象？
How to construct/map domain objects from external data sources?
我知道两种方法。
最常见的是，应用程序通过对值的共同理解与领域模型进行通信。该应用程序采用其具有的表示形式（例如，文件中的字节），并从中构建域模型可以理解的表示形式。您可能会通过工厂（了解如何将原始值转换为值类型）或构建器来完成此操作。
The most common is that the application communicates with the domain model via a common understanding of values. The application takes the representation that it has (for example, bytes in a file), and builds from it a representation that the domain model will understand. You might see this done via a factory (that understands how to convert primitive values to a value type) or a builder.
罕见的方法是应用程序采用其具有的表示形式，并将其包装在域模型可以识别的适配器中（与构建具体类型相反）。在这种样式中，值类型看起来更像角色接口，使域模型对基础数据模型一无所知。
The rarer approach is that the application takes the representation that it has, and wraps it in an adapter that the domain model will recognize (as opposed to building a concrete type). In this style, value types look more like role interfaces, keeping the domain model ignorant of the underlying data model.
如果域对象创建需要来自多个源的数据（服务，文件，数据库），是否意味着应用程序服务和基础结构（存储库）之间应该存在一个单独的层，该层从多个存储库中提取数据，是否进行所有映射并返回结果域对象？
If domain object creation requires data from multiple sources (services, file, db), does it mean that there should be a separate layer between application service and infrastructure (repository) that pulls the data from multiple repositories, does all the mapping and returns resulting domain object?
我希望存储库本身可以完成这项工作-存储库的作用是键值存储的抽象。
I would expect the repository to be doing that work itself - the role of the repository is the abstraction of a key-value store.
我们建议改为从一系列困难的设计决策或可能改变的设计决策开始。然后，每个模块都被设计为对其他模块隐藏这样的决定。
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
选择服务/文件/数据库是应该做出的一个决定示例。隐藏在模块（存储库）中的模块（其界面被选择为尽可能少地揭示其内部工作原理）。
The choice of services/files/db is one example of a decision that should be hidden within a module (the repository) whose interface "was chosen to reveal as little as possible about its inner workings".
这篇关于外部数据映射到域的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
