Design basato sul dominio - Indirizzo entità / valore

Question

Design basato sul dominio - Indirizzo entità / valore

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

2

Ho un indirizzo come parte del mio dominio. L'indirizzo conserva informazioni su paese, città, codice postale, via e numero civico. È utilizzato in più luoghi - una società può avere un indirizzo di ufficio, indirizzo di fatturazione e / o indirizzo di corrispondenza; i trasporti hanno indirizzi ai punti iniziale, intermedio e finale; anche un paio di altri posti.

Mi chiedo come gestire correttamente questo modo DDD. L'indirizzo dovrebbe essere un oggetto valore, un'entità o una radice aggregata? Ho visto domande simili ma non sorprendentemente nessuna di queste corrispondeva bene al mio dominio.

Un indirizzo non sa come convalidare se stesso - gli indirizzi dell'azienda possono essere inizialmente quasi vuoti e riempiti in seguito, ma gli indirizzi del trasporto dovrebbero essere sempre completi. Quindi generalmente dipende dall'oggetto che contiene un indirizzo, non dall'indirizzo stesso.

La prossima cosa è che l'indirizzo di una società è completamente indipendente dagli indirizzi di altre società - evento se sono gli stessi in termini di posizione. Inoltre, cambiare l'indirizzo dell'azienda non significa sostituirlo con un altro: è solo un aggiornamento fatto all'oggetto corrente. Inoltre non influisce su nessun altro indirizzo. Questo da solo qualifica l'indirizzo come entità?

Poiché l'indirizzo non può funzionare da solo, non dovrebbe essere AG, giusto?

Forse l'indirizzo dovrebbe essere solo un'interfaccia con CompanyAddress, TransportAddress ecc. che la implementa? Stanno seguendo regole diverse dopotutto ...

Apprezzerei molto la tua opinione su questo. Mi sento come se mi mancasse qualcosa qui, ma non riesco a capire cosa esattamente.

domain-driven-design

posta webfreak 08.02.2018 - 14:42

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design

microservizi metodi granularità Design: aggiorna le proprietà su un'entità in un'API RESTful basata su risorse

score 1 · Answer 1

Mi sembra che tu abbia effettivamente due oggetti distinti qui, Address e Location . Un Location potrebbe essere utilizzato per rappresentare un ufficio aziendale o qualche altro luogo concettuale, ma un Address sarebbe un oggetto valore che rappresenta una posizione fisica. Un Address non cambia mai, ma la proprietà Address di Location può essere modificata da un oggetto valore Address a un altro con un evento appropriato.

score 0 · Answer 2

I feel like I'm missing something here but can't quite figure out what exactly.

Una cosa facile da perdere è che le entità racchiudono dei valori. Vale a dire, le entità "hanno" lo stato attuale e lo stato è un valore .

Vedi il discorso di Stuart Halloway, Percezione e azione .

Quale entità è è un riferimento mutabile allo stato immutabile.

State before = mutableRef.get()
State after = computeNextState(before)
mutableRef.swap(before, after)

In altre parole, un'entità è una mappatura temporalmente variabile allo stato.

Dobbiamo essere cauti nella nostra modellazione in termini di comprensione quando vogliamo riferirci a un riferimento (che ci dà accesso a diversi stati, a seconda di quando lo diamo la parola), e quando vogliamo lo stato.

Considera un esempio di spedizione; potresti avere un indirizzo di spedizione predefinito corrente; quando effettui un ordine, il tuo ordine necessita anche di un indirizzo di spedizione. Riddle: se cambi il tuo indirizzo di spedizione predefinito dopo aver effettuato un ordine, la destinazione della tua spedizione dovrebbe cambiare? È importante se facciamo questa domanda prima che il pacchetto abbia lasciato il centro di evasione ordini?

Un altro è che valori semanticamente differenti possono avere una rappresentazione comune, ed è importante non confondere i due. Ad esempio, UnvalidatedEmailAddress e ValidatedEmailAddress sono semanticamente differenti, ma le rappresentazioni in byte probabilmente assomigliano ancora a [email protected] .

Scott Wlaschin ha alcuni materiali accessibili che dettagliano questo, e il suo nuovo libro, Domain Modelling Made Functional , è abbastanza buono.

Parte del punto è prendere distinzioni semantiche implicite, come il diverso tra Company.Address e Transport.Address, e renderle esplicite.

score 0 · Answer 3

Indirizzo in Azienda e Trasporti, sembra un buon esempio di entità simile (Indirizzo) utilizzato in più contesti limitati con diff. regole aziendali.

Quindi se il tuo indirizzo aziendale ha diff. regola aziendale e indirizzo di trasporto ha diff. regola aziendale per aver bisogno di diff. Tipo di oggetto come IndirizzoSabbia e Indirizzo di trasporto

Ora la domanda dovrebbe essere AggregateRoot, ValueObject o Entity, penso che possano essere qualsiasi cosa basata su come la tua azienda le modella, preferirò come Root Aggregato in caso di Company e come ValueObject in caso di Transport