Usi multipli della stessa entità

Question

Usi multipli della stessa entità

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

2

Attualmente stiamo progettando un sistema in cui un utente può commentare su più argomenti. I soggetti possono essere un'immagine, un post, ecc. Un commento dovrebbe essere modificabile e cancellabile. Conterrebbe solo testo (per ora). Un commento può essere inserito solo se il soggetto lo consente. Nella prima mano, modellerei come segue:

| Comment  (AR) |
| - Subject     |
| - Text        |

| Subject (VO)  |
| - PictureID   |
| - PostID      |

Tuttavia, il problema è che il servizio commenti deve essere in grado di sapere se l'utente è autorizzato a commentare una determinata immagine o post (a seconda delle impostazioni sulla privacy, f.e). Quindi ha bisogno di conoscere le entità Soggetto. Anche la frase Un utente può commentare un post o una foto mi chiede se il commento debba essere un AR stesso. Questo non renderebbe il commento un aggregato degli aggregati di radici Picture e Post? In questo modo:

| Post (AR)    |
| CommentIDs[] |
| ...

| Picture(AR)  |
| CommentIDs[] |
| ... 

| Comment  (AR) |
| - Text        |

Ma ora, inserendo i commenti all'interno di Post e Picture, si potrebbero far esplodere questi aggregati e creare enormi limiti di trx quando iniziano le grandi discussioni. Sono un po 'perso qui, e continuo a girare tra questi 2 modelli.

domain-driven-design

posta Pepster 11.12.2018 - 16:40

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design

Utilizzo di Map per passare i parametri di query in DAO Gestione utenti: Identity Management di terze parti vs utente locale

score 1 · Answer 1

I modelli di creazione degli oggetti possono essere complicati.

Detto questo, non vedo nulla nelle tue regole che indichi che è necessario che Picture/Post abbia bisogno di un riferimento al loro List<CommentId> . Ad esempio:

comment = picture.addComment( text );

sembra un modo accettabile e incentrato sul dominio per creare un nuovo Comment in base alle regole specificate dall'oggetto ( Picture/Post ).

score 1 · Answer 2

Penso che il tuo problema principale sia confondere il modello DB con il tuo modello di dominio e provare a mappare ogni riga DB esattamente a una classe.

Ci sono due contesti in gioco qui. Stai visualizzando un soggetto e i suoi commenti, oppure stai modificando un commento (si potrebbe sostenere che la modifica di un soggetto è un terzo, ma il punto è che non si modifica mai un soggetto e un commento allo stesso tempo).

Durante la visualizzazione dell'oggetto, il commento può essere un oggetto valore CommentVO. Questo oggetto valore non ha bisogno di tutto il comportamento che avrebbe un vero commento radice di aggregazione, e probabilmente nemmeno le stesse proprietà.

Quando si modifica un commento, è necessaria la versione di CommentAR che presenta un comportamento.

Queste due classi possono essere mappate sulla stessa tabella DB poiché il VO non apporta mai alcuna modifica.

Avere il soggetto in possesso di un elenco di CommentVOs consente di gestire le sue entità secondarie secondo necessità e il grafico dell'oggetto non diventa pericolosamente alto. Consenti solo la modifica di un CommentAR poiché ha la convalida e altri comportamenti necessari. Il soggetto avrebbe un metodo AddComment (CommentAR) per legare insieme i due. Probabilmente avresti un Subject.DeleteComment (CommentoVO) a meno che non sia necessario un qualche tipo di logica di cancellazione.