La tua nuova architettura non deriva anche da Domain Driven Design. Ovviamente nel contesto di schemi tattici (poiché lo schema dei modelli di strategia va oltre il codice).
In Domain Driven Design hai molti elementi utili che possono aiutarti a gestire la complessità accidentale del tuo sistema. Ma prima di iniziare a applicarli devi rispondere a una domanda molto importante
Ho veramente bisogno dei blocchi costitutivi DDD nel mio sistema / modulo?
La risposta dovrebbe essere sì se il tuo sistema ha una ricca logica di business non solo semplice CRUD (è ovviamente una semplificazione, hai molti articoli a riguardo).
Nota: mi riferisco alla parte tattica di DDD. Credo davvero nell'uso dell'evento di modelli strategici DDD per applicazioni di tipo CRUD (ad esempio, linguaggio ubiquitario).
OK, dato che l'argomento è molto ampio ti darò alcuni semplici passaggi che puoi intrecciare nel tuo sistema (è più semplice il concetto di architettura esagonale).
1) Dividi la tua applicazione in moduli. Sarebbero più di meno voi Contesti delimitati . Come farlo in Java? Utilizza i pacchetti - sono davvero potenti.
Quindi avrai per esempio com.mycompany.mysystem.order, com.mycompany.mysystem.invoice
2) il tuo contesto limitato sarà costruito su alcuni aggregati . L'aggregato è tutto ciò che dovrebbe essere elaborato in un'unica transazione. La radice del tuo aggregato può essere rappresentata come entità JPA.
@Entity
class Order {
@Id
String id;
List<Product> products;
void addProductToOrder(...) {
... some business logic
}
Money calculateDiscount(...) {
... some business logic
}
Le tue Entità dovrebbero essere Entità Ricche - contengono comportamenti, non solo preservano la struttura. Puoi anche usare concetti come oggetti valore immutabili.
3) Crea repository per il tuo aggregato, ma solo per la tua parte aziendale, in modo che tu possa salvare il tuo aggregato e recuperarlo. Puoi usare ad es. Dati primaverili.
4) Crea facciata per raccogliere i metodi necessari per eseguire alcune azioni. È possibile mantenere la convalida lì, ma ricorda che il comportamento stesso deve essere mantenuto all'interno di aggregati.
5) Puoi utilizzare anche altri modelli come Factory, Strategy, Observer, ecc. Tutti i pattern OO si adattano bene al DDD.
6) Mantieni tutte queste classi nel pacchetto di domini, ad es.
com.mycompany.mysystem.order.domain
- Order.java
- OrderRepository.java
- OrderFacade.java
- OrderFactory.java
Solo OrderFacade dovrebbe essere pubblico. Altre classi dovrebbero avere scope del pacchetto.
7) Ora puoi creare un altro sottopacchetto - infrastruttura. Manterrai la configurazione Spring lì, Rest Controller, ecc. Tutto ciò che non è relativo al dominio.
com.mycompany.mysystem.order.domain
- Order.java
- OrderRepository.java
- OrderFacade.java
- OrderFactory.java
com.mycompany.mysystem.order.infrastructure
- OrderCommandController.java
- OrderConfiguration.java
8) C'è un concetto molto potente usato spesso con DDD. Si chiama CQRS . Puoi leggere a riguardo, ci sono molte fonti. Ti darò un consiglio su come aggiungerlo all'esempio sopra.
Hai situazioni in cui devi recuperare qualcosa dal database in milioni di modi? Sì, lo fanno tutti.
Quindi secondo CQRS puoi dividere i tuoi comandi / operazioni aziendali e query. Seguendo il nostro esempio, crea un nuovo sotto pacchetto
com.mycompany.mysystem.order.query
All'interno puoi creare Entità chiamata OrderQuery e indirizzarla alla stessa tabella nel database (o usare la proiezione in casi più avanzati). Ora puoi creare un nuovo repository (Spring Data) e usarlo con OrderQuery. Nel sotto pacchetto infrastruttura aggiungere il nuovo controller OrderQueryController.
Questi passaggi sono ovviamente solo uno scheletro e contengono molte semplificazioni. Dovrebbe essere sufficiente per iniziare e guidarti in buona direzione.