Architettura di implementazione multipla in un singolo contesto limitato?

Question

Architettura di implementazione multipla in un singolo contesto limitato?

#1 da (2 voti)
#2 da (2 voti)

3

In tutti i libri DDD che ho letto fino ad ora, dicono che un contesto limitato può avere una propria architettura di implementazione, che suggerisce una singola architettura per contesto limitato .

Nel mio viaggio di DDD e anche CQRS, ho trovato in un contesto limitato, alcuni concetti di dominio sono adatti per un modello di dominio ricco, quindi avrò radici aggregate, oggetti valore ed entità per quelli. Ma oltre a quelli, ho un certo numero di cose che sono semplici ma strettamente correlate a quei concetti di dominio.

Ad esempio, nella mia applicazione, gli utenti possono aggiungerne altri come utenti, creare un gruppo di chat aggiungendo molti utenti, aggiungere post, ecc. Quindi ho radici aggregate per utenti, gruppi di chat, post. Ma ci sono cose come bloccare un altro utente, contrassegnare un utente come importante, contrassegnare un gruppo di chat come importante. Si tratta principalmente di impostazioni che implicano una relazione user-user o una relazione user-chatgroup . È un modello imbarazzante queste cose come aggregati. Ogni diversa impostazione non è molto correlata agli altri, quindi raggruppare tutte le impostazioni di user-user in un grande aggregato è anche strano.

Al momento, per me è più semplice avere due implementare l'architettura all'interno di un contesto limitato : 1) DDD per quei concetti complessi 2) script di transazione per quelle cose semplici. È accettabile?

Oltre al pensiero sopra menzionato, ho anche pensato di suddividerli in più contesti limitati. Ma sono preoccupato di come combinare i dati in due contesti limitati in uno nella fase di interrogazione. Nel caso di un utente che sta interrogando un altro utente, desidera vedere tutte le cose relative a quell'utente. In termini di api riposante, l'utente desidera vedere:

{
    "userId": 12, //from ddd
    "Name": "Somebody", //from ddd 
    "IsFriend": true, //from ddd
    "IsImportant": true, //from transaction script
    "Blocked": false //from transaction script
}

Ma dato che DDD di solito suggerisce ogni contesto limitato dovrebbe avere il proprio database ed è meglio non condividere un database. Posso fare compromessi per condividere database solo allo scopo di interrogare (non scrivere), ma non sono ancora sicuro se potrebbero esserci problemi che non posso prevedere in questo momento.

Mi piacerebbe sentire opinioni e suggerimenti. Grazie in anticipo.

domain-driven-design

posta foresightyj 05.03.2016 - 04:30

fonte

2 risposte

2

Hm, direi che è assolutamente plausibile modellare le relazioni utente-utente come una proprietà di un utente. Quindi, se hai interrogato l'utente corrente, avresti:

{
    userid: ...,
    otherAttributes: ...,
    blockedUsers: [userid1, userid2],
    importantUsers: [userId3, userid4]
}

Al di fuori del contesto dell'utente non avrebbe molto senso, quindi si inserirà perfettamente nel tuo aggregato utente. Le relazioni utente-chat sono equivalenti.

risposta data 05.03.2016 - 07:34

fonte

Leggi altre domande sui tag domain-driven-design

Il modo migliore per usare un api in stile C ++ da un file in stile C compilato in C ++ Come gestisci i comportamenti specifici per paese?

score 2 · Accepted Answer

It is awkward model these things as aggregates

Perché? Dato che stai usando CQRS, questi aggregati verrebbero utilizzati solo sul lato della scrittura. Sarebbe imbarazzante se dovessi caricare tutti questi piccoli aggregati in memoria ogni volta che viene visualizzata una schermata, ma con CQRS puoi avere query ad-hoc che otterranno tutti i dati necessari in una volta dal database.

Il problema con il mix di approcci DDD e non DDD nello stesso Contesto Limitato è la coerenza IMO e la sicurezza futura. Non appena trovi un'invarianza che si sovrappone a un aggregato e uno script di transazione, dovrai trasferire tutti gli oggetti che stai utilizzando nello script di transazione sul dominio DDD che può essere una riscrittura significativa.

Un'altra opzione potrebbe essere quella di creare un Contesto Limitato separato - PersonalRelationships o qualcosa del genere. Ma solo tu e i tuoi esperti di dominio potete capire se

Questa area funzionale è qualcosa che probabilmente cambierà indipendentemente dal resto
Varrà la spesa aggiuntiva in termini di database separato, forse repository di codice separati, build e processo di distribuzione.
Sei pronto ad accettare che tutto accada in un modo alla fine coerente. Ad esempio, un utente che viene rimosso dal sistema non verrà immediatamente rimosso dall'elenco di utenti importanti di un altro utente. Inoltre, se il sistema di chat è in un altro BC, ci sarà un piccolo ritardo fino a quando un utente che hai bloccato non può chattare con te. Questo tipo di cose.