In Domain Driven Design quando un'entità clona se stessa che la aggiunge al suo contenitore?

Question

Ad esempio, abbiamo due oggetti dominio: Cell e Body (come nella cella e nel corpo umani).

La classe Body è solo una raccolta di celle, ad es.

class Body 
{ 
    IList<Cell> cells; 
    public void AddCell(Cell c) { ... } 
    public void RemoveCell(Cell c) { ... } 
} 

La cella ha un metodo di divisione, che crea internamente un clone di se stesso, ad es.

Class Cell 
{ 
    public Cell Split() 
    { 
     Cell newCell = new Cell(); 
     // Copy this cell's properties into the new cell. 
     return Cell; 
    } 
} 

Ora, in DDD quando le divisioni cellulari voglia:

1. La cella aggiungere la cella appena creato al corpo (il che significherebbe che ciascun oggetto cellulare tenuto un riferimento al suo corpo di contenimento)?
2. Oppure il livello di servizio che ha ricevuto la richiesta di chiamata iniziale chiamata Chiama, raccoglie la cella restituita e la aggiunge al Corpo? (sembra un design più anemico usando i controller piuttosto che gli oggetti di dominio)
3. O il Body deve contenere un metodo SplitCell?

Grazie in anticipo.

Answer 1

Dopo aver letto Domain Driven Design (Evans) sembrerebbe che questo scenario è migliore affrontato utilizzando uno service.

Answer 2

In DDD, spesso dipende, beh, dal dominio. Qui, l'esempio - e quindi il dominio - sembra un po 'strano, ma penso che opterei per un metodo SplitCell su Body.

Sebbene non sia molto chiaro per me cosa significhi la divisione cellulare e cosa debba scatenare questa azione, suppongo che il corpo sia responsabile della divisione delle sue celle. Sarei più a mio agio con un metodo Regenerate, o qualcosa del genere, su Body, che divide le celle interne chiamando il metodo Split su ciascuna di esse.

Ok, questo esempio è definitivamente bizzarro ...

Answer 3

mi piacerebbe pensare che il corpo sarebbe semplicemente chiamare lo splitCell() sulla cellula. Quindi il Corpo può fare ciò che vuole con la nuova Cella - aggiungere a se stesso, consumarlo, buttarlo via, qualunque cosa. Il corpo contiene comunque la cella.

Answer 4

Ok - un altro approccio sarebbe quello di inviare un evento al corpo dicendo "Sto dividendo" o qualsiasi altra cosa. E il corpo può quindi raccogliere la nuova cella - forse come carico utile di quell'evento.

Se il tuo attore esterno non conosce il corpo, il metodo Split deve restituire un nuovo clone di cella? L'attore esterno lo userà in qualche modo? Oppure il metodo Split non può restituire nulla (Void) e semplicemente inviare un messaggio al Corpo in cui vive?

Answer 5

L'utilizzo degli eventi nella classe Cell sembra una soluzione naturale, ma è più difficile da implementare in C#.

Avrete bisogno di collegare eventi quando Cells entrano in campo, e dovrete anche sganciarli quando escono dall'ambito, altrimenti otterrete perdite di memoria.

È inoltre necessario collegare eventi ogni volta che una cella viene ri-associata a Body, ad esempio quando le celle vengono recuperate da un archivio di persistenza. Utilizzare un contenitore per gestire le relazioni (possibilmente un intercettore ORM) potrebbe renderlo più semplice.

L'alternativa più semplice è quello di mantenere un riferimento al genitore Body (cellule appartenere solo a un singolo Body, giusto?), E lasciare che il nuovo Cell si aggiungono alla sua Body.

• Pro: Facile da codificare, eseguire il debug, capire.
• Contro: cellulare e corpo diventano strettamente accoppiati, che li rende più difficile da riutilizzare in altri contesti (che può essere irrilevante)