In generale dovresti dividere la tua applicazione in pacchetti funzionali piuttosto che strutturali. Ad esempio, quale è l'eccezione aziendale ("Ordine non trovato", ad esempio) in un pacchetto di eccezioni generali?
Dovresti avere un'elevata coesione all'interno dei pacchetti. Preferirei dividere un singolo pacchetto in più strati che dividerli per il loro scopo strutturale / architettonico. Ad esempio, credo che il modello meriti un proprio livello con tutte le sue necessità. Quindi, per il modello specifico, avrei un livello applicativo con controller e possibilmente un altro layer intercambiabile con viste, il tutto legato con interfacce ben definite.
La tua seconda opzione porta chiaramente ad un'architettura in cui molte parti della tua applicazione avranno dipendenze non necessarie e indesiderate. Questo limiterà le tue opzioni di flessibilità ed estensibilità. Pensaci: ogni volta che cambi una singola interfaccia nel pacchetto del modello, tutti i pacchetti che usano questo pacchetto devono avere anche una dipendenza aggiornata.
In breve, strutturerei un'applicazione di base come questa:
package1
model (subpackage/assembly, contains the business logic)
application (subpackage/assembly, contains controllers etc)
presentation (subpackage/assembly, contains views etc.)
interfaces (optional, encapsulates well defined interfaces
so the layers can communicate and for Dependency Injection)
I livelli possono essere spazi dei nomi fisicamente distinti. La distinzione fisica (la compilazione di diverse DLL) aiuta davvero a mantenere pulita la tua architettura, la parte delle interfacce può essere un gatekeeper.
Sappi anche che il termine modello può significare cose diverse. Il modello può fare riferimento alla logica aziendale (in OOP principalmente un modello a oggetti del tuo dominio aziendale) o a un singolo "modello di presentazione" (a questo punto non mi riferisco al modello di Fowler al 100%, ma piuttosto alle miriadi di varianti MVC in generale) ". Mentre il primo appartiene veramente al pacchetto del modello, quest'ultimo appartiene al livello dell'applicazione. Mi piace molto MVC quando il controller chiama solo la business logic e il livello di persistenza. La maggior parte delle volte non ha bisogno di un modello separato.