Il modello di dominio dovrebbe essere intelligente o ci devono essere servizi che lo gestiscono?

4

Sto costruendo una web-app per un servizio di licenze. I miei modelli di dominio sono licenze e possono essere di due tipi al momento: server e licenza client. Sono quasi gli stessi, tranne che la licenza server ha il campo softwareId e la licenza client ha hardwareIdArray (le licenze client possono essere registrate su più client).

Quindi, ho un modello di base Licenza con i suoi figli: ClientLicense e ServerLicense , che portano campi aggiuntivi.

I modelli di ogni tipo vengono prelevati dai rispettivi repository (utilizzo il framework TYPO3 Extbase, dove è standard e consigliato).

Ora arriva la parte interessante: ogni licenza ha alcune informazioni aggiuntive, che non posso persistere (beh, posso, ma solo nella cache temporanea), ma invece dovrei recuperarla dal servizio REST (es. "expirationDate", che può essere modificato al di fuori della mia web-app). E per ogni tipo di licenza queste informazioni aggiuntive potrebbero essere diverse e possono essere recuperate con un metodo diverso in REST API. Inoltre, ogni tipo di licenza ha un metodo activate () REST diverso. Allo stesso tempo ci sono metodi REST comuni, come getLicenseFile () .

Quindi, ho deciso di nascondere tutta questa roba interna nella classe LicenseService , che è consigliata per comunicare da controllori o altre classi, che necessitano di alcune informazioni sulla licenza. LicenseService comunica a LicenseRestApi , che contiene alcune funzionalità di basso livello per eseguire richieste REST.

E qui arriva una domanda: chi dovrebbe sapere su ciascuna funzionalità specifica del tipo di licenza? F.e. quando un controller richiede un servizio a getAllLicenses ($ user) , è un servizio, che dovrebbe determinare un tipo di licenza e quindi eseguire chiamate al rispettivo repository e metodi appropriati in RestApi; o una licenza dovrebbe sapere tutto su se stessa e chiamare RestApi; o alcune nuove classi, come ClientLicenseProcessor e ServerLicenseProcessor , a cui dovrebbe comunicare LicenseService e tutte le comunicazioni con RestApi dovrebbero essere all'interno di questi processori , quindi in in questo caso LicenseService fungerà da FactoryMethod per la creazione del processore appropriato?

Il mio obiettivo è mantenere una logica di tipo specifica in un unico posto e non distribuirla tra più classi.

    
posta Viktor Livakivskyi 21.08.2015 - 11:48
fonte

1 risposta

4

Il servizio non dovrebbe prendere alcuna decisione o si finisce con un modello di dominio anemico . La tua licenza aggregata dovrebbe prendere le decisioni. Se l'aggregato della licenza deve chiamare un servizio Web, si passa un'istanza di un helper per quel servizio al metodo sull'aggregato. Può loro scegliere di usarli se lo desidera.

    
risposta data 21.08.2015 - 12:14
fonte

Leggi altre domande sui tag