Decostruzione di contesti limitati del software monolite per la progettazione basata su domini

Dovresti analizzare tutte le differenze di comportamento dai reparti per prendere la decisione architettonica corretta. Il caso più semplice è quello in cui si realizza un solo prodotto (un singolo contesto limitato, ad esempio TaskManagement) utilizzato da tutti i reparti.

Da quanto ho capito finora, le differenze riguardano solo l'autorizzazione: alcuni reparti possono assegnare compiti solo ad alcuni utenti, altri reparti possono assegnare compiti a tutti utenti e così via. Questo può essere estratto in un modulo separato che corrisponde a un contesto limitato separato: Autorizzazione. Ciò significa che il contesto limitato TaskManagement non è influenzato da queste differenze, un'attività ha lo stesso comportamento per tutti i reparti.

L'autorizzazione è ampiamente discussa su libri / Internet, ma come un piccolo suggerimento di implementazione, è possibile effettuare le chiamate al contesto limitato Autorizzazione nel livello Applicazione, prima delle chiamate agli Aggregati dal contesto limitato TaskManagement; l'interfaccia utente utilizza anche il contesto limitato Autorizzazione, per caricare l'elenco utenti corrispondente quando viene assegnata un'attività.

TaskManagement è un contesto limitato che può consentire soluzioni off-the-shelf. Ad esempio, Jira viene utilizzata da molte aziende e da tutti i dipartimenti di tali società. Nel caso peggiore, è possibile avere diverse istanze dell'applicazione TaskManagement per ciascun reparto, con un database diverso, ma con lo stesso codice sorgente.

I'm starting to dive into domain driven design for a new project.

The software solution will be used by several departments to assign tasks to their employees.

The task assignment process is mostly similar for these departments. One of the differences is that some departments assign tasks to their employees only, others need employees from the other departments.

Posso identificare due motivi per cui questa differenza potrebbe essere significativa:

1. Un dipartimento deve applicare una regola aziendale che impedisca di assegnare attività a qualsiasi dipendente che non sia il proprio. Altrimenti, a chi importa?

2. Un reparto assegna principalmente compiti a sé stessi, mentre un altro assegna principalmente compiti ad altri. Ciò crea un problema di interfaccia utente perché i dipendenti più probabili dovrebbero essere i più facili da trovare.

Now for the DDD, should I consider each department as a separate bounded context, or divide it according to features (ie. task assignment, users pool, reports, ...)

Ragioni per raggruppare per reparto:

1. Responsabile di una sola fonte di cambiamento.
2. L'esperto di domini deve solo fornire un linguaggio ubiquo per un dominio limitato alla sua esperienza.
3. Le comunicazioni tra domini possono essere modellate sulla comunicazione tra reparti.
4. Il raggruppamento per dipartimento ti consente di sfruttare la conoscenza della singola azienda

Motivi per non raggruppare per reparto:

1. Man mano che l'azienda cresce, i dipartimenti possono creare delle responsabilità
2. Le responsabilità dei dipartimenti possono sovrapporsi
3. Il raggruppamento per dipartimento richiede di sfruttare la conoscenza delle singole aziende piuttosto che rimanere generico.

And one final question, how to handle code duplication in separate contexts?

Non eccedere ASCIUTTO. Do not Repeat Yourself non è mai stato concepito per costringerti a setacciare la base di codice per ogni espressione di ciclo e matematica che potrebbe assomigliare a ciò che stai per scrivere. La duplicazione che consente a responsabilità simili in luoghi diversi di reagire al cambiamento variando in modo indipendente è una buona cosa. È solo quando una decisione di progettazione viene diffusa in più luoghi, luoghi che dovranno cambiare tutti insieme quando la decisione cambia, che inizierò a picchiarti con la levetta DRY. Si tratta di prendere decisioni in un unico posto. Non si tratta di come appare il codice.