Quando dovresti creare un sottosistema?

Non ci può essere una linea guida generale per questo.

1. I progetti software sono molto diversi. Alcuni sono piccoli e non necessitano di alcun sottosistema. Alcuni sono enormi e consistono in centinaia di sottosistemi che a loro volta hanno i loro sottosistemi. Non tutti i sistemi hanno un database o un'interfaccia utente.

2. Ci sono anche molti modi per definire un "sottosistema". Un sottosistema potrebbe essere una classe separata, un pacchetto, una libreria, un progetto, un microservizio o un numero di altre cose. A volte ha senso organizzare il codice in un pacchetto separato, a volte ha senso creare un servizio completamente separato. Entrambi sono una specie di sottosistema, ma sono su scale completamente diverse.

Un modo utile per pensare ai sottosistemi è Domain Driven Design (DDD). Questo non riguarda davvero i sistemi, ma la definizione del tuo dominio problematico . Succede quindi che molti progetti software si estendano su domini diversi. Il DDD suggerisce di stabilire dei chiari confini concettuali tra quelli (un contesto limitato ). Un contesto limitato è un buon candidato per qualche sottosistema separato, ma dipende da te decidere come dovrebbe essere rappresentato nel tuo software. Questo dipende molto dalla complessità di quel sistema, dalla tua organizzazione e dalle tue esigenze.

Direi che esiste una linea guida generale. Se riesci a isolare parti che non devono sapere sulla parte rimanente, devi dividere il tuo sistema. Spesso finirai con una parte che serve l'altra (quindi puoi parlare di un sottosistema).

Le parti separate saranno probabilmente più utili, possono essere applicate in diversi scenari. Ti sarai creato dei blocchi predefiniti.

Si tratta di separare le responsabilità. Dovresti finire con blocchi che fanno solo una cosa. Come i dati del negozio o i dati di trasporto. Allora sarai in buona forma, puoi cambiare un blocco o addirittura sostituirlo senza rompere (dovendo fare molto lavoro con nessuno degli altri blocchi.