Mi piacciono il design guidato da domini e il design a cipolla. Comunque mi piacerebbe davvero che le mie caratteristiche fossero incapsulate. Se controllo qualche codice legacy e ho bisogno di investigare su alcune caratteristiche specifiche, la cosa migliore che penso possa accadermi è che vedo (diciamo in java) che ci sarebbe un pacchetto con featurename e tutte le funzionalità la funzionalità risiedeva in quel pacchetto. In modo che se elimini il pacchetto la funzionalità sarebbe andata.
Pur comprendendo che è impossibile perché alcune delle funzionalità potrebbero risiedere in altri servizi, sto tentando almeno di pensare se è corretto farlo nel mio servizio.
Il mio problema con questo è che di solito in DDD e in onion design hai il dominio che contiene un gruppo di oggetti di dominio. ora alcuni di questi oggetti sono di "mia funzionalità" e alcuni di essi sono di altre funzionalità. diciamo (l'autenticazione dell'utente è una funzione e i dettagli dell'account Twitter dell'utente sono un'altra caratteristica).
Esiste qualche metodologia di progettazione che faccia qualcosa con esso? è quello che sto suggerendo ha senso?
Esempio: hai un progetto che gestisce gli utenti in attesa in linea. Ti viene chiesto di aggiungere un limite, massimo sulla dimensione della coda. è necessario leggere la dimensione massima della coda dalla configurazione. Quindi nella tua logica è necessario applicare la dimensione massima della coda. È inoltre necessario esporre questa configurazione della dimensione massima della coda in jmx, inoltre è disponibile una API per quel servizio, quindi è necessario esporre la dimensione massima della coda come API in quel servizio.
Pacchetti di app correnti:
--> conf (deals with reading configuration) // do change here.
--> domain // do change here for that small subfeature.
--> logic // do change also here for that small subfeature
--> service (where api are) // do also a change here.
quindi nell'esempio semplicistico di cui sopra per una semplice aggiunta subfeature ho bisogno di apportare modifiche ad almeno 4 pacchetti. Ciò significa che la mia sottofunzione è diffusa tra questi pacchetti e classi.
Capisco DDD menzioni boundcontext ma nota che la mia funzione qui è molto piccola! aggiungendo solo una limitazione massima alle dimensioni. Quindi non sembra appropriato aprire un boundedcontext su ciascuna di queste piccole sottofunzioni.
Quindi, il modo in cui lo gestisco oggi vado a trovare una classe chiamata Configuration che contiene varie configurazioni. Aggiungo a quel Configuration class un membro chiamato Configuration.maxQueueSize .
Vado quindi al dominio per modellare quella nuova proprietà che ho lì diciamo Account aggiungo alla Account class Account.maxQueueSize .
Vado quindi al servizio di esporre un nuovo metodo denominato getMaxQueueSize
come vedi sono passato a più pacchetti e più classes ha già a che fare con altre funzionalità e le ho estese.
Questa è una caratteristica molto piccola, per una sola cosa non riesco a immaginare che per ogni piccola feticista aprirei un nuovo contesto limitato con i suoi pacchetti service, domain, conf (e ne deduco che ce ne siano altri) in modo che ogni funzionalità sia in il proprio pacchetto.
D'altra parte su ogni funzione ho bisogno di estendere configuration, domain, service, ... il che significa che nessuna singola funzione è incapsulata abbastanza bene in modo che io possa semplicemente cancellarla o vedere un pacchetto in cui risiede completamente in modo da poter capire meglio l'app .