Architettura dell'applicazione software modulare

La risposta di Arseni Mourzenko non è male, ma suppongo che non abbia coperto la tua domanda per intero. Sono d'accordo sul fatto che il controllo delle funzioni dal punto di vista degli utenti finali è per lo più indipendente dalla struttura interna dei componenti di un prodotto software. Il controllo delle caratteristiche è IMHO il criterio di decisione errato per "usare un grande componente" rispetto a "usando molti piccoli".

Tuttavia, la struttura dei componenti interni è importante pesantemente dal punto di vista di un ingegnere del software. Il principale consenso oggi è che lo sviluppo di molte piccole componenti indipendenti, che sono per lo più disgiunte le une dalle altre, ognuna con una sola responsabilità, è molto più facile che sviluppare una componente enorme e complessa con molte responsabilità. Questo è sicuramente un compromesso, molti piccoli componenti richiedono, come già menzionato, interfacce aggiuntive e un modo per scambiare dati (come dati utente o informazioni di sessione) tra di loro. Tuttavia, sul lato pro c'è

• sviluppo parallelo molto migliore (ogni componente può essere sviluppato da un diverso team o persona in parallelo)
• molto più testabilità, manutenibilità ed evolvibilità (ciascuno dei singoli componenti può essere testato da solo, il che rende più facile scrivere test automatici, identificare la causa principale dei bug e gestire le modifiche)

Naturalmente, non esiste un "proiettile d'argento" o un consenso su come dovrebbero essere i componenti "piccoli". Ciò dipende in gran parte dalle dimensioni complessive del sistema e dalle dimensioni del team: più sono grandi, più diventa importante dividere l'architettura di un sistema in componenti più piccoli.

Ad esempio, nel mondo dei servizi web, questa discussione porta all'idea di Microservizi . Tuttavia, per i piccoli prodotti e gli sviluppatori solisti, tale architettura potrebbe essere troppo finita e potrebbe aggiungere troppo spese generali aggiuntive.

Non sappiamo quanto grande sia il tuo sistema e il tuo team, quindi solo tu puoi prendere una decisione se hai bisogno di molti piccoli componenti o meno (ma, come ho detto inizialmente, non basato sul fatto che devi fornire funzionalità controllo).

Tecnicamente, non importa.

Guarda Netflix. Quanti prodotti vedi? Solo uno. Eppure, Netflix è un conglomerato di dozzine di servizi che possono essere sviluppati e distribuiti indipendentemente, utilizzando uno stack tecnologico indipendente.

Ora guarda un sito web SquareSpace casuale. E poi sceglierne un altro. Possono non avere nulla in comune. Due prodotti diversi, utilizzando due diversi set di funzionalità. E ancora, il codice di programmazione sottostante è lo stesso per entrambi.

Quindi, se la domanda non è tecnica, cos'è e, cosa più importante, chi decide?

Il punto attuale è come presentare il prodotto a un cliente. Potrebbe avere senso presentare una serie di funzionalità come un singolo prodotto. Oppure potrebbe essere più utile presentare il sistema come più prodotti.

Porta Microsoft Office. Codice condiviso (eccetto Excel), più prodotti. Hai PowerPoint e hai Word, non perché sarebbe tecnicamente impossibile combinare entrambe le funzionalità di un editor di testo e un editor di presentazione in un unico prodotto software, ma piuttosto perché gli utenti non capirebbero come utilizzare tale prodotto (secondo Microsoft ).

Ora considera Visual Studio. Se scrivo codice C # per le applicazioni server, e questo è tutto ciò che faccio, non mi interessa davvero Visual Basic, F # o C ++. E non mi interessa nemmeno Silverlight, WPF o Windows Form. Tuttavia, è tutto in Visual Studio, in una forma di funzionalità. Tutto in un posto. Un punto interessante è che non è sempre stato così. Negli anni novanta, dovevi installare IDE diversi per lingue diverse: se hai usato due lingue, hai finito con Microsoft Visual Basic e Microsoft Visual C ++ sul tuo computer.

Pertanto, la decisione spetta esclusivamente al marketing. Una volta presa la decisione, spetta a te sviluppare il prodotto software in modo da garantire una sufficiente coesione tra le parti del sistema ed evitare la duplicazione del codice.