Su cosa concentrarsi quando si separa un codebase monolitico in pacchetti separati (NuGet)?

6

Lavoro su un'applicazione web abbastanza grande. La soluzione principale contenente il progetto di applicazione web ha oltre 100 progetti. Il tempo di costruzione medio di quella soluzione è di 2 minuti su una macchina quad-core da 12 GB con un SSD.

Stiamo esaminando i modi in cui possiamo migliorare il nostro processo di implementazione. Ho intenzione di lavorare su un proof-of-concept per spostare il codice dal repository principale in repository separati, da costruire e confezionare come pacchetti NuGet. Questi saranno ospitati su un feed interno e installati nella soluzione principale da lì.

Per la proof-of-concept voglio concentrarmi sugli aspetti più importanti / stimolanti. Ho un po 'di esperienza nella creazione di librerie stand-alone e, naturalmente, l'esperienza di lavorare su questo codice base monolitico. Vorrei chiederti:

A cosa dovrei concentrarmi per la dimostrazione del concetto?

Alcune aree penso che dovrei sperimentare:

  • Versioning

  • Associazione di assiemi

  • Test dell'unità

  • ILMerge per unire le dipendenze

  • Debug

  • Performance

PS. Automatizzare la costruzione e la pubblicazione di pacchetti nel repository NuGet non è una mia responsabilità.

    
posta Michiel van Oosterhout 25.03.2014 - 21:49
fonte

1 risposta

1

NuGet è solo un gestore di pacchetti. A patto che sia al centro della tua domanda, puoi davvero dire che l'architettura del tuo progetto è già abbastanza buona e che manca solo la gestione dei pacchetti? Altrimenti, forse, la domanda dovrebbe essere riformulata per concentrarsi sul refactoring dell'architettura monolitica piuttosto che sull'introduzione della gestione dei pacchetti?

Detto questo, ecco cosa ha funzionato per me:

1) affetta le soluzioni tra business e limiti di preoccupazione: ad es. persone, autenticazione, moduli aziendali;

2) applica l'architettura dei micro-servizi;

3) pacchetto i tipi e le funzioni di helper molto comuni: pacchetto framework.

4) pacchetto i modelli comuni / preoccupazioni trasversali: pacchetto Pattern repository, pacchetto di registrazione, pacchetto di memorizzazione nella cache, pacchetto REST ecc.

5) crea un pacchetto client per ogni micro-servizio per trarre vantaggio dalla strong tipizzazione.

    
risposta data 04.08.2014 - 11:09
fonte

Leggi altre domande sui tag