Domain driven design DDD与数据导出系统

我是DDD的初学者，在体系结构方面遇到了一些小问题

我们的系统必须能够以各种格式（Excel、Word、PDF和其他更奇特的格式）导出业务数据

在您看来，哪一层必须负责检索源数据、以目标格式导出源数据以及为用户准备最终结果的整个过程？我混淆了域和应用程序的责任

---

关于导出子系统，实现和它们的公共接口契约是否应该属于基础架构层？

我通常尽可能采用简单的方法

域代码实现域的语言-名词、动词等

应用程序代码使用此语言创建诗歌

因此，在您的示例中，输出的构造是应用程序关注的问题，而应用程序将要讨论的位的构造（因为您没有提到它）将是域关注的问题

---

e、 g.如果报告由销售数据组成，则日期、账单、订单等将在域中抽象构造，而应用程序将使用这些数据生成文档。

应用程序层、域层或任何其他“层”均不可用。DDD不是分层体系结构。搜索有关此主题的mor的onion体系结构或端口和适配器模式

现在谈谈你问题的核心。您面临的问题是一个单独的有界上下文，应该转到系统的一个单独组件。我们称之为报告。由于这只是一个表示问题，没有域逻辑-DDD不适合它。只需创建一些SQL视图，使用NHibernate、LINQ2SQL、EF甚至普通数据读取器读取它们，然后使用构建器模式构建Word/任何文档。没有聚合、存储库、服务或任何其他DDD构建块

---

您可能希望更进一步，让应用程序中的所有数据表示都由单独的组件处理。这是CQRS。

首先，感谢您的快速回复！事实上，我忘了详细说明生成的文档的性质。业务数据必须导出为通用用户文档（Word、Excel、PDF、HTML），但也必须导出为专有格式，以使我们的系统在相关业务领域具有互操作性。这些并不是为了演示的目的，只是关心原始数据。我会在域层中实现所有关于特定专有格式的东西。你觉得这个设计好看吗？对于“泛型文档”，我同意您在域层生成一种抽象文档。感谢您的帮助。不，我将采用@Bartłomiej建议的方法-专有输出将只是域中实体基于表示关注的转换。非常感谢您的宝贵建议！