Struttura dell'applicazione Java: divisione orizzontale o verticale

Avere un po 'di dibattito sulla struttura iniziale del progetto (usando Maven / Eclipse) per una grande applicazione Java.

Opzione 1:

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

Opzione 2:

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

L'opzione 2 si tradurrà chiaramente in molti più progetti / moduli Maven e significa che le classi che genererebbero il database sono distribuite tra più progetti. Qualcuno potrebbe consigliare pro / contro di ogni approccio?

Suggerirei di non fare nessuno dei due.

Cercare di imporre una stratificazione tecnica con una struttura del pacchetto porta a un sacco di problemi nella tua applicazione. Per non parlare del fatto che ci sforziamo così tanto di nascondere tutto dietro un'interfaccia di servizio e la prima cosa che facciamo (principalmente a causa del packaging) è rendere tutto a public class. Questo diventa doloroso quando c'è una separazione tecnica tra un x.y.z.servicee x.y.z.repositorypacchetto, ora tutto può accedere al repository. Boom va lì l'incapsulamento all'interno del livello di servizio.

Invece dovresti seguire un approccio più funzionale e basato sulla cipolla ( architettura pulita , architettura esagonale ). Ciò è anche in linea con il principio di responsabilità singola (se applicato a un pacchetto) e anche in conformità con i principi di imballaggio

1. Le cose che cambiano insieme vengono impacchettate insieme
2. Le cose che vengono usate insieme vengono impacchettate insieme

Oliver Gierke ha scritto un bel post sui componenti di packaging insieme in Java. Simon Brown ha scritto una storia più generale sull'argomento.

Vorrei lottare per una struttura di pacchetto di base come la seguente per contenere il nucleo della tua applicazione:

x.y.z.area1
x.y.z.area2

Ora se hai un'interfaccia web aggiungi, ad esempio, un websubpackage, affinché webservice a wso restpackage ne contenga solo. Si collega sostanzialmente al core.

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

Ora potresti considerare di riutilizzare gli oggetti dall'interno del tuo core negli altri livelli, ma IMHO è meglio usare un dominio specifico per quel livello. Come nel caso della mappatura di Object to SQL, c'è (spesso) una discrepanza tra ciò che vogliamo mostrare sullo schermo o usare come XML nel servizio web e come viene implementata la logica aziendale. A seconda della complessità dei domini di business e web che li potrebbe considerare come domini separati problema da risolvere, che hanno bisogno di essere collegati, fondamentalmente 2 differenti contesti limitati .

Per utilizzare un preventivo da una risorsa CQRS

Non è possibile creare una soluzione ottimale per la ricerca, la reportistica e l'elaborazione delle transazioni utilizzando un singolo modello.

Non cercare di mettere tutto in un unico modello (dominio), separare le responsabilità. Probabilmente finirai con più classi (più piccole) ma una separazione più pulita tra i livelli dell'applicazione.

Nota finale

Ricordare che creare un'architettura è decidere i compromessi di una soluzione all'altra. Dipende fortemente dalla complessità del dominio e dovrebbe essere guidato principalmente dai requisiti funzionali dell'applicazione. Tuttavia è influenzato da vincoli non funzionali (prestazioni, sicurezza) e ambientali (linguaggio da usare, piattaforma, esperienza). E l'architettura, come la codifica, non ha mai finito ogni nuovo requisito può (e forse dovrebbe?) Portare a una riprogettazione dell'applicazione.

disconoscimento

Sì, ho anche provato a mettere tutto in un unico modello, e sì, ho anche provato a utilizzare una separazione tecnica nelle mie applicazioni. Tuttavia dopo un paio d'anni di esperienza nella creazione di livelli di applicazione aggrovigliati (all'inizio sembra una buona idea, quindi l'applicazione inizia a crescere ...) Ho pensato che ci doveva essere un altro modo.

link

1. Architettura pulita, zio Bob Martin
2. Hexagonal Architecture (aka Ports and Adapters), Alistair Cockburn
3. Whoops dove è andata la mia architettura, Oliver Gierke
4. Principi di OOD, zio Bob Martin
5. Errori durante l'applicazione di DDD, Udi Dahan
6. Contesti limitati, Martin Fowler
7. Stile di codifica architettonicamente evidente, Simon Brown

Libri

1. Software orientato agli oggetti in crescita, guidato da test
2. Architettura delle applicazioni Java: modelli di modularità con esempi che utilizzano OSGi (serie Robert C. Martin)
3. Design guidato dal dominio: affrontare la complessità nel cuore del software
4. Architettura software per sviluppatori
5. Implementazione del design guidato dal dominio