DDD, un'entità, molti sottotipi

0

Ho una domanda sulla modellazione.

Introduzione rapida: sviluppo applicazioni a fini di vendita. L'applicazione ha utenti. Ogni utente può essere cliente, dipendente o amministratore dell'azienda.

Dipende da:

Cliente: solo account registrato e acquista prodotto da qualsiasi società registrata

L'account registrato dal dipendente e il proprietario dell'azienda gli assegnano un ruolo dipendente.

Proprietario dell'azienda - account registrato e negozio creato.

ma il proprietario dell'azienda potrebbe essere anche un cliente, proprio come un dipendente.

Sono arrivato con una relazione semplice

utente della classe

cliente di classe: utente

impiegato della classe: utente

class owner: user

In questo modo posso facilmente incapsulare la logica per ogni RUOLO? (il ruolo è una parola chiave) Nella peggiore delle ipotesi potrei mappare tutto in BD alla tabella per ogni sottoclasse.

O dovrei lasciare l'utente semplice e creare una gerarchia di ruoli che incapsuli la logica?

cliente classe ruolo classe utente: dipendente classe ruolo: classe ruoloOwner: ruolo

e con associazioni semplici potrei

user.AssignRole (new Employee (company));

user.Roles.where (x = > x è Employee) .DoSth ()?

BTW: potrei rinominare "ruolo" in "attore"

E riguardo la radice aggregata in entrambi i casi? Se utilizzo la stessa entità (utente) come cliente e stessa entità (utente) come dipendente.

Che cosa succede quando 2 o più persone usano la stessa entità nello stesso tempo con diversi limiti di confine (cliente, dipendente)?

La domanda principale è: è buona progettazione se un'entità database può essere mostrata in molti tipi?

    
posta user2440890 14.09.2016 - 01:26
fonte

1 risposta

1

Penso che preferirei la composizione sull'eredità qui. La complessità della sottoclasse non sembra giustificata. Separerei le persone (utenti) dai loro ruoli; per dirlo in un altro modo, non penso che sia una relazione tra le persone e i loro ruoli.

Ad esempio, i ruoli cambiano. E per un altro, una persona può riempire più ruoli (ed è difficile da modellare con la sottoclasse).

Lascia che la struttura delle persone riguardi le persone e la struttura dei ruoli sui ruoli, e associalo / collegali secondo le necessità.

    
risposta data 14.09.2016 - 06:14
fonte

Leggi altre domande sui tag