Architettura a cipolla applicata a un'applicazione .NET

Sto cercando di capire come tradurre l'architettura di cipolla in una soluzione WebAPI di base di ASP.NET, questo è quello che ho trovato:

Diciamo che ho un'applicazione che accetta un file path / uri in input tramite un'applicazione Console o un'applicazione WebAPI, leggi ogni riga e se alcune regole di business sono soddisfatte cambia la linea in un determinato formato specifico di business e se no restituisce un errore come nuova linea. L'applicazione in Console e WebAPI deve essere in grado di restituire l'output (le righe modificate con i nuovi formati e gli errori che corrispondono a una data classe (ValueObject?) A Json e Xml.

• Application.Console : una semplice CLI che può consumare un
• Application.Console.Tests : test della CLI
• Application.WebApi : esponendo il
• Application.WebApi.Tests :
• Domain
• Domain.Tests

Ciò di cui sto lottando e non sono sicuro:

• Mi sarei aspettato di avere un Infrastructure + Infrastructure.Tests ma poiché non ho realmente la necessità di usare un atm Database / EF Core, penso che sia inutile, a meno che non metta la configurazione di la configurazione Swagger / Swashbuckle + Logging nel livello Infrastructure, ma non sono sicuro che questo sia il posto a cui appartiene.

• Non so davvero dove mettere il file IO che legge la parte nel livello Infrastructure o in un altro Application.Core , ovviamente questo strato si baserebbe su quello del dominio ed essere consumato da entrambe le applicazioni.

• Per alcune ragioni, penso che se entrambe le applicazioni richiedono gli stessi formati di output, allora è meglio che la parte di formattazione sia implementata in qualcosa di comune invece di eseguire lo stesso tipo di azione sia in Application.Console che Application.WebApi (anche se sarebbero stati eseguiti "" diversamente "" sulla superficie:

  • Il progetto della console utilizzerà direttamente Newton JSON o XmlSerializer (o un'altra libreria di serializzazione XML).
  • Il WebApi sfrutterà i formattatori incorporati: link

• Finalmente vedo in alcuni altri progetti che i controller che sono in genere nella parte WebApi vengono a volte spostati in un progetto dedicato. Non sono sicuro se abbia molto senso quando c'è 1 Controller + 1 Azione nell'intera soluzione. In modo che Program.cs e Startup.cs si trovino in un progetto Host. Potrebbe essere un po 'eccessivo se non voglio che i miei test siano ovviamente collegati a quel progetto ( MyProjectName / MyProjectName.Tests ) e test di integrazione (usando Tester: link ) collegato all'host (non è sicuro che abbia molto senso)