DDD: l'utente dovrebbe essere un concetto di dominio?

Question

DDD: l'utente dovrebbe essere un concetto di dominio?

#1 da (8 voti)
#2 da (2 voti)
#3 da (2 voti)

5

Prendiamo qualche applicazione per i blog. L'utente in questa applicazione ha e-mail, password. Quando un nuovo utente è registrato, deve attivare il suo account (ad esempio, via email). Ma ... l'attivazione dell'account, la password, i token di reimpostazione della password, ecc. Sono concetti di dominio?

Quindi sto pensando di dividere il concetto dell'utente in 2 parti: account e membro. Un account non è un concetto di dominio, gestirà l'attivazione, la reimpostazione della password, ecc. Ma il membro è un concetto di dominio, un membro non ha nulla a proposito di password, attivazione, ecc.

Un account avrà riferimento a un membro.

Cosa ne pensi di questo approccio? o l'utente può essere una parte del dominio?

domain-driven-design

posta Teimuraz 13.12.2016 - 12:29

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design

Dovrei avere un ramo 'dev' separato da un ramo 'produzione'? Proprietà / metodi multipli che danno lo stesso risultato

score 8 · Answer 1

Account e membri sono due rappresentazioni di utenti in contesti diversi .

Il punto di Domain-Driven Design è che noi affermiamo chiaramente il dominio del problema o il contesto limitato di ciascun (sotto) sistema. Possiamo quindi sviluppare modelli separati per ogni contesto. Lo stesso concetto di "Utente" può essere rappresentato in modo diverso in diversi modelli: "Account" per il sistema di autenticazione e "Membro" per il sistema di blog.

La gestione dell'account non fa parte del tuo dominio principale, è corretto. Tuttavia, è probabile che tu abbia o utilizzi un altro sistema o un subsysten per la gestione dell'account. Il dominio problematico di tale sistema include la gestione degli account.

Alcuni concetti in diversi concetti limitati si sovrappongono o rappresentano la stessa entità. Dovrai tradurre i tuoi concetti quando attraversi un limite di contesto - non è una buona idea riutilizzare parti del modello in contesti.

score 2 · Answer 2

2

Se stai modellando i domini, dovresti stare lontano dai luoghi comuni. User è un tale luogo comune. In realtà è tutto e niente. Sii concreto e chiamalo Blogger . Questo lo renderà immediatamente un concetto di dominio.

risposta data 13.12.2016 - 12:41

fonte

score 2 · Answer 3

But... is account activation, password, password reset tokens, etc, are domain concepts?

Perché non dovrebbero essere? Gli utenti (blogger, ospiti, commentatori ecc.) Devono entrare nel sistema in qualche modo. Se il dominio non affronta queste regole aziendali, chi lo farà?

Hai ragione a separare Account e Member in entità separate. Ma invertirò la dipendenza. Un Account è solo un nome utente e una password (e probabilmente un salato e alcune informazioni di controllo). Non dovrebbe sapere nulla sull'appartenenza. Puoi avere un account senza essere un membro, ma non puoi essere un membro senza avere un account. Member può anche avere un Profile , che può essere di più tipi: Blogger , Guest ecc.