DDD infrastructure layer project type

I’m working on a DDD-based architecture using WPF. Currently, my Domain, Application, and Infrastructure layers are all implemented as .NET Standard projects, though I’m not certain if that’s the best choice. In my scenario, WPF needs to generate a PDF report based on XML data stored in the database. For instance, the IReportRepository interface in the Domain layer currently returns the report name along with the report XML as a string. The challenge is that to export the report as a PDF, the WPF client must use Microsoft.Reporting.WinForms.LocalReport (from the NuGet package ReportViewerCore.NETCore)—passing the XML, loading queries, rendering, and exporting the PDF. I’d like to add a method like GetPdfBytes(reportId) to the repository interface. However, implementing this in the Infrastructure layer is difficult because Microsoft.Reporting.WinForms.LocalReport and the ReportViewerCore.NETCore package aren’t compatible with .NET Standard. If I switch my Infrastructure project from .NET Standard to .NET 8, I can install ReportViewerCore.NETCore and handle PDF rendering there. However, I’m unsure if upgrading Infrastructure to .NET 8 is the right approach—especially since the Application layer, which depends on Infrastructure, would also need to be upgraded to .NET 8. Meanwhile, the Domain layer would remain on .NET Standard. My concerns are: Is switching Infrastructure and Application layers to .NET 8 a valid and recommended approach? What are the potential benefits and drawbacks of this switch that I might be overlooking? Are there alternative solutions to implement PDF generation without upgrading Infrastructure to .NET 8? Additionally, multiple projects reference the backend. For example: WPF client calls Application layer’s GetPdfBytes method. A background service (worker.cs) running on the server also needs to generate PDF bytes by calling the same Application layer method. So the call flows look like: WPF → Application Layer → GetPdfBytes and Worker.cs → Application Layer → GetPdfBytes What would be the best practice or recommended approach in this scenario?

May 22, 2025 - 07:30

I’m working on a DDD-based architecture using WPF. Currently, my Domain, Application, and Infrastructure layers are all implemented as .NET Standard projects, though I’m not certain if that’s the best choice.

In my scenario, WPF needs to generate a PDF report based on XML data stored in the database. For instance, the IReportRepository interface in the Domain layer currently returns the report name along with the report XML as a string.

The challenge is that to export the report as a PDF, the WPF client must use Microsoft.Reporting.WinForms.LocalReport (from the NuGet package ReportViewerCore.NETCore)—passing the XML, loading queries, rendering, and exporting the PDF.

I’d like to add a method like GetPdfBytes(reportId) to the repository interface. However, implementing this in the Infrastructure layer is difficult because Microsoft.Reporting.WinForms.LocalReport and the ReportViewerCore.NETCore package aren’t compatible with .NET Standard.

If I switch my Infrastructure project from .NET Standard to .NET 8, I can install ReportViewerCore.NETCore and handle PDF rendering there. However, I’m unsure if upgrading Infrastructure to .NET 8 is the right approach—especially since the Application layer, which depends on Infrastructure, would also need to be upgraded to .NET 8. Meanwhile, the Domain layer would remain on .NET Standard.

My concerns are:

Is switching Infrastructure and Application layers to .NET 8 a valid and recommended approach?

What are the potential benefits and drawbacks of this switch that I might be overlooking?

Are there alternative solutions to implement PDF generation without upgrading Infrastructure to .NET 8?

Additionally, multiple projects reference the backend. For example:

WPF client calls Application layer’s GetPdfBytes method.

A background service (worker.cs) running on the server also needs to generate PDF bytes by calling the same Application layer method.

So the call flows look like: WPF → Application Layer → GetPdfBytes and Worker.cs → Application Layer → GetPdfBytes

What would be the best practice or recommended approach in this scenario?