平面文件工作單元 (DDD) 的相關性？

Question

所以，我正在開發一個 DDD 應用程序，我將跳過細節，但全局：其中一項服務旨在從數據庫中檢索信息，處理它並將“處理過的數據”（實際上是一個聚合）寫入一個平面文件（不，我不能改變這一點 - 平面文件將被發送到可以解釋該文件的打印機）。 除了平面文件部分，沒有什么特別之處。 寫代碼的時候，我在想，當然，我需要將處理數據的結果寫入文件作為我的應用程序服務的一部分，對我來說，這與使用單元將聚合寫入數據庫相同通過存儲庫類的工作。

所以我的問題是：作為 DDD 的一部分，FlatFileUnitOfWork 是否合法？ 如果是這樣，有沒有人有一個（好的）例子？ 因為對我來說，這是相當罕見的，而且我無法找到“FlatFileUnitOfWork”的正確示例。

非常感謝。

注意：Web API 是用 C# 編寫的

Answer 1

加入TSeng ，我會說這取決於！ :)

根據您的描述，工作單元不太可能適合您的情況。 什么是合適的解決方案，在DDD 中，顧名思義，取決於域！ - （編輯：縮短）

我的問題是：印刷背后的業務流程是什么。 這只是一個小問題 - 還是核心領域的關鍵部分（例如，整個應用程序是關於革命性地打印出酷設計的音樂會門票） - 還是介於兩者之間？

如果這只是一件小事——距離很遠，與核心領域無關——那么應用程序事件或命令可能沒問題。 例如，您在核心域的上下文中發出一個應用程序事件，然后在另一個上下文中捕獲該事件，該上下文通過向打印機發送該平面文件來讓打印機完成其工作。 或者，此打印可能屬於同一上下文（仍然是一個小問題） 。 在這種情況下，您的應用程序服務可能會調用（或“命令”）基礎結構層的 porper 模塊，通過平面文件進行打印。

如果它是核心域的一部分，那么它可能會發生，例如域服務以某種方式負責編寫關鍵的打印內容 - 或類似的東西。 在這種情況下，解決方案的精確細節將取決於對核心領域的徹底分析（知識分析、領域建模） 。

編輯 - 示例案例

對於我的示例案例，我假設您有一個門票打印微服務，這是您的核心領域，因為您正在打印有史以來最酷的音樂會門票，這是整個應用程序的重點。

在這個服務中，我想你有一個復雜的域模型來構建最酷的票務布局，在它之上有一個TicketComposer ，它提供了一個TicketToPrint值對象，其中包含打印所需的所有重要信息 - 例如像這樣：

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

在這種情況下，您的基礎設施層中需要一個TicketPrinter類，該類負責打印該票據。 您的域和應用程序層甚至都不應該知道它是如何做到的。 即您的應用程序服務方法看起來像這樣：

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 ，基礎設施層中的TicketPrinter完成您要求的工作：

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

此示例是否回答了您的問題？

Answer 2

打印機看起來像 DDD 的 UI 層，它只是“顯示”數據。

您應該有某種 Presenter 將聚合傳遞給某個基礎設施服務，該服務負責將聚合轉換為打印機可以理解的格式。