Trattare con i modelli di dominio in continua crescita

Certamente puoi progettare il modello come ti proponi, ma alla fine finirai con una (molto) grande palla di fango. Non sei il primo ad incontrare questo problema, ecco perché appaiono concetti come SOA, microservizi e DDD.

L'idea è che le preoccupazioni della tua applicazione possano essere raggruppate in un modo relativamente indipendente l'una dall'altra (servizi). Ad esempio, il fatto che un membro del personale appartenga a uno o più reparti, abbia una macchina e abbia un elenco di elementi del flusso di lavoro, non significa che questi concetti siano necessari in un unico posto per eseguire la logica richiesta.

Il modulo parcheggio deve conoscere i dipartimenti dei membri del personale? e il loro flusso di lavoro? Probabilmente no. E la lista delle macchine? probabilmente sì. Quindi il tuo modulo carpark potrebbe avere un elenco di membri dello staff con le loro macchine, ma non con i loro elementi del flusso di lavoro.

Si noti che un altro servizio potrebbe anche avere un elenco di membri dello staff con altre proprietà. Non si tratta di dati duplicati, perché fondamentalmente condividono gli ID membri del personale, ma non i dati effettivi, semplicemente perché i dati utilizzati da un servizio sono irrilevanti per un altro servizio.

Se segui questo approccio, vedrai che non c'è una singola entità "Staff member" nella tua applicazione. Ogni servizio ha "un pezzo" di membro del personale, una proiezione del tutto che è rilevante in quel contesto. In DDD, diversi contesti limitati potrebbero contenere lo stesso concetto, come "ordine" o "cliente", ma con un significato diverso.

Questo approccio introduce alcune complessità. Ad esempio, consistenza finale. In questa configurazione, un servizio sarà incaricato di creare (assumere?) Ed eliminare (terminando il contratto) dei membri dello staff. Quando ciò accade, questo servizio pubblicherà un evento come StaffMemberHired o StaffMemberContractTerminated. Gli altri servizi ascolteranno questi eventi e agiranno di conseguenza. Ad esempio, il servizio carpark creerà una voce nell'elenco dei membri del personale del parcheggio. Da questo momento, il modulo consentirà a un utente di assegnare un'automobile e un posto auto al nuovo membro dello staff. Quando il modulo carpark riceve l'evento StaffMemberContractTerminated, annulla l'assegnazione dei posti di parcheggio e contrassegna la voce del membro dello staff come terminata, in modo che non sarà più possibile assegnarvi un posto di parcheggio. L'eventuale consistenza implica che esiste la possibilità che per un breve periodo di tempo venga creato un membro dello staff e che non sia ancora disponibile per assegnare un posto auto, o che sia terminato, ma il posto auto è ancora riservato. Queste situazioni sono risolte in tempi molto brevi normalmente.

Questi concetti sono un po 'confusi da comprendere all'inizio e talvolta un po' difficili da applicare, ma risolvono la tua domanda: consentono un dominio in continua crescita, perché in pratica aggiungi nuovi servizi al sistema, invece di aumentare le dimensioni di un singolo modello.

I problemi complicati sono complicati. Di solito non c'è modo di risolverlo. Possiamo solo mescolare la complessità in modo che appaia meno complicata: dividere la complessità secondo vari criteri o nascondere una certa complessità dietro un'astrazione.

Per il tuo modello di dominio, potresti notare che domini di problemi diversi come "booking time slot" e "gestione di una flotta di macchine" hanno entità sovrapposte come membri dello staff, ma sono altrimenti completamente separati. Domain Driven Design suggerisce che questi possono essere modellati come "contesti limitati" separati.

• Nel contesto di prenotazione della fascia oraria possiamo avere un'entità staff che è associata alle fasce orarie disponibili.
• Nel contesto della gestione della flotta, possiamo avere un'entità driver separata associata a un numero di automobili.

Entrambi questi modelli staff / driver rappresentano lo stesso membro del personale, ma sono modellati separatamente: il modello non è condiviso in tutti i contesti. Invece, traduciamo tra i modelli al limite di contesto. Ciò ti consente di evitare la necessità di una classe diStaff gargantuan% con dozzine di proprietà.

Sebbene ciò renda il modello più semplice perché ogni singolo contesto è ora molto più piccolo e le proprietà non correlate non sono più impigliate tra loro, la complessità complessiva potrebbe essere aumentata perché ora dobbiamo gestire più contesti e più entità che rappresentano lo stesso personale membro - stiamo mescolando la complessità in giro. Devi decidere se valga la pena nel tuo caso.