La struttura del pacchetto dovrebbe assomigliare molto alla gerarchia delle classi?

Secondo Uncle Bob , le classi dovrebbero essere raggruppate in pacchetti se cambiano insieme. Presumibilmente, se class A cambia, allora class AFactory dovrebbe essere modificato, ma class BFactory non lo farebbe. Quindi, se A e B non sono correlati, ognuno di essi dovrebbe trovarsi in un pacchetto separato insieme al factory corrispondente. D'altra parte, se c'è una dipendenza tra A e B che ti obbliga a cambiarne una quando cambi l'altra, allora le due classi e le due fabbriche dovrebbero essere tutte nello stesso pacchetto.

Se segui questo modello, dovresti essere in grado di creare ciascun pacchetto in una libreria separata, indipendentemente dall'altra.

Stai facendo la domanda sbagliata. Non è se qualcosa sia una buona o una cattiva idea, ma se sia utile.

Considera un altro sviluppatore che ha a che fare con il tuo codice. Cosa capiranno dalla struttura del pacchetto? Migliorerà la loro comprensione e capacità di mantenere ed espandere il tuo codice, o vorrà cambiarlo?

Gli aspetti tecnici di OO sono chiari, ereditarietà e polimorfismo (strumenti / estensioni), tra gli altri, e questi sono evidenti dal codice, insieme ai modelli di progettazione. La struttura e la denominazione del pacchetto dovrebbero descrivere gli scopi e le funzionalità del codice di base (ad esempio cos'è un xxxImpl e come funziona?)

La risposta precedente parla di accoppiamento e può essere di aiuto nello sviluppo generale, ma avere gli obiettivi e le esigenze aziendali chiaramente definiti nella struttura generale è molto più utile.