平面文件工作单元 (DDD) 相关性？

Question

所以，我正在开发一个 DDD 应用程序，我将跳过细节，但在全球范围内：其中一项服务旨在从数据库中检索信息、处理它并编写 "processed data"（一个实际上聚合）成一个平面文件（不，我不能改变它 - 平面文件将被发送到可以解释该文件的打印机）。除了平面文件部分外，没有什么不寻常的。在写代码的时候，我在想，当然，我需要将处理后的数据的结果写入一个文件，作为我的应用程序服务的一部分，对我来说，这与使用一个单元将一个聚合写入数据库是一样的通过存储库 class 完成的工作。

所以我的问题是：作为 DDD 的一部分，FlatFileUnitOfWork 是否合法？如果是这样，有人有（好的）例子吗？因为对我来说，这很不常见，而且我找不到 "FlatFileUnitOfWork".

的正确示例

非常感谢。

注意：Web API 是用 C# 编写的

Answer 1

加入，我会说这取决于！ :)

根据您的描述，工作单元不太可能适合您的情况。在DDD，顾名思义，什么是正确的解决方案取决于域！ - （编辑：缩短）

我的问题是：打印背后的业务流程是什么。这只是一个小问题 - 或者它是核心领域的关键部分 （例如，整个应用程序是关于革命性地打印出设计精美的音乐会门票） - 或者介于两者之间？

如果这只是一件小事 - 很远，与核心域无关 - 那么应用程序事件或命令可能没问题。例如。您在核心域的上下文中发出应用程序事件，然后在另一个上下文中捕获该事件，另一个上下文让打印机通过向其发送该平面文件来完成其工作。或者，此打印可能属于相同的上下文 （仍然是一个小问题）。在这种情况下，您的应用程序服务可能会调用 （或 "command"） 基础设施层的 porper 模块，通过平面文件进行打印。

如果它是核心域的一部分，那么它可能会发生，例如域服务以某种方式负责编写关键的打印内容 - 或者类似的东西。在这种情况下，解决方案的精确细节将取决于对核心领域的全面分析（知识处理，领域建模）。

编辑 - 示例案例

对于我的示例案例，我假设您有一个票据打印微服务，这是您的核心领域，因为您正在打印最酷的音乐会门票，这是整个应用程序的重点。

在此服务中，我想您有一个复杂的域模型来构建最酷的票证布局，在该模型之上有一个 TicketComposer 提供一个 TicketToPrint 值对象，其中包含您需要的所有重要信息需要打印 - 例如像这样：

public TicketToPrint ComposeTicketToPrint(SoldTicket ticket)
{
    // ...
}

在这种情况下，您的 基础结构 层中需要一个 TicketPrinter class，由其负责打印该票证。您的 Domain 和 Application 层都不应该知道它是如何做到的。 IE。您的应用程序服务方法将如下所示：

public void PrintSoldTicket(SoldTicketDTO ticketDto)
{
    SoldTicket soldTicket = CreateSoldTicket(ticketDto);

    var composer = new TicketComposer();
    TicketToPrint ticketToPrint = composer.ComposeTicketToPrint(soldTicket);

    var printer = new TicketPrinter();
    printer.Print(ticketToPrint);
}

然后在链的末端，基础结构 层中的 TicketPrinter 完成您要求的工作：

public void Print(TicketToPrint ticketToPrint)
{
    // Creating the flat file and sending it to the printer...
}

这个示例是否回答了您的问题？

Answer 2

打印机看起来像来自 DDD 的 UI 层，它只是 "displays" 数据。

您应该有某种 Presenter 将聚合传递给一些基础结构服务，该服务负责将聚合转换为打印机可以理解的格式。

平面文件工作单元 (DDD) 相关性？

A flat file Unit of Work (DDD) pertinence?

c#

domain-driven-design

unit-of-work