Saubere Architektur und API-Verträge in .NET 10 ⇐ C#

[Anonymous]

Ich baue eine ASP.NET Core 10-Web-API. Ich versuche mein Bestes, die Clean Architecture-Prinzipien zusammen mit CQRS (MediatR) zu befolgen.
Die Ebenenstruktur:

• Code: Select all

  API

  (Abhängigkeiten: Anwendung und Infrastruktur nur für DI-Zwecke)

• Code: Select all

  Infrastructure

  (Abhängigkeiten: Anwendung)

• Code: Select all

  Application

  (Abhängigkeiten: Domäne)

• Code: Select all

  Domain

  (unabhängig)

Es gibt einen Trend, Verträge (Anfragen und Antworten) in einem separaten unabhängigen Projekt oder einer separaten Ebene abzulegen, um sie mit anderen Systemen zu teilen. Ich bin bei diesem Ansatz auf mehrere Probleme gestoßen und würde gerne jemandes Meinung dazu hören.
Problem 1: Angesichts der Tatsache, dass die Vertragsebene unabhängig ist, ist die Arbeit mit Dateien die Hölle. Ich kann IFormFile nicht in Anforderungs-DTOs verwenden, da die Ebene selbst eine einfache Klassenbibliothek ist.
Problem 2: Die Vertragsebene kann nicht von der Domänenebene abhängen, da sie die Domänenlogik offenlegen könnte, was zu einem DRY-Problem führen könnte. Ich habe eine einfache Sex-Aufzählung in meiner Domänenschicht:

Code: Select all

namespace MovieStore.Domain.Users;

public enum Sex
{
Male = 0,
Female = 1
}

Wenn ich ein Anforderungs-DTO zum Erstellen eines Benutzers definieren möchte, muss ich ein Duplikat meiner Domänenaufzählung erstellen, was eine weitere Zuordnung erfordert. Die Duplizierung kann behoben werden, indem sex in der Anfrage als int definiert und dann in meinem Handler auf Sex abgebildet wird. Dieser Ansatz führt jedoch zu API-Dokumentationsproblemen (Aufzählungen werden von OpenAPI gut dokumentiert, während int nichts über Optionen aussagt).
Problem 3: Es ist sinnvoll, die API-Anforderungs- und die CQRS-Befehlsobjekte der Anwendungsschicht zu unterscheiden, da die API eine Datei möglicherweise als IFormFile akzeptiert, während der Befehl der Anwendungsebene dies erwartet Streamen. Ich bin mir nicht sicher, ob die Trennung der API- und Anwendungsantwortobjekte sinnvoll ist, da sie größtenteils identisch sind (ich kann mir nicht vorstellen, dass sie unterschiedlich sind). Für die Duplizierung ist eine erneute Zuordnung erforderlich. Lohnt es sich?
Eine Vertragstrennung hat mehr Nachteile als Vorteile. Ich denke, dass es viel einfacher ist, Anfragen/Antworten in der API-Schicht zu verwalten, aber es löst Problem Nr. 3 nicht, weil die Anwendungsschicht die API-Schicht-Antwort-DTOs nicht sieht, was zu Duplikaten führt.