DDD和数据导出系统答案

【问题标题】：DDD and data export systemDDD和数据导出系统
【发布时间】：2012-10-08 07:44:06
【问题描述】：

我是 DDD 的初学者，在架构方面遇到了一点问题。

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

在您看来，哪一层必须负责检索源数据、以目标格式导出它们并为用户准备最终结果的整个过程？我对域和应用程序职责感到困惑。

关于导出子系统，实现及其公共接口契约是否应该属于基础设施层？

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

既不是应用程序层，也不是域层或任何其他“层”。 DDD 不是分层架构。搜索有关此主题的 mor 的洋葱架构或端口和适配器模式。

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

您可能想要更进一步，让应用程序中的所有数据呈现都由单独的组件处理。那是 CQRS。

【讨论】：

【解决方案2】：

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

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

应用程序代码使用这种语言创作诗歌。

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

例如如果报告包含销售数据，那么日期、账单、订单等内容将在域中抽象地构建，而应用程序将关注使用这些数据生成文档。

【讨论】：

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