DDD - modellazione di categorie simili con comportamento differente

Question

DDD - modellazione di categorie simili con comportamento differente

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

1

Ho una domanda relativa alla modellazione di classi di oggetti simili in un DB:

Supponiamo che nel database io abbia una lista di clienti che possono essere in diverse categorie - es. Cliente - > può essere in Categoria1 ... Categoria10

ora, Client in Category1 ha un comportamento specifico solo per quel tipo di client, ma i client in Category2 ... Category10 ha un comportamento comune.

Devo avere una classe separata per ciascuna delle diverse categorie di clienti (probabilmente overkill), o dovrei avere solo 2 classi ClientCategory1 e ClientCategory2to10?

È meglio modellarlo come classe Client e avere una proprietà interna con tipo di categoria. Quindi questo comportamento specifico per ClientCategory1 può eseguire il controllo if (category == 1) {solo in questo caso; }? Il problema con questo approccio è che la classe Client potrebbe contenere metodi a volte applicabili (solo categoria1) e altri metodi sarebbero applicabili solo per altre categorie.

domain-driven-design data-modeling

posta Marko Kraljevic 06.08.2016 - 13:13

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design data-modeling

Dove si trova l'onere della responsabilità e del supporto di componenti / servizi condivisi? Distribuzione di un'applicazione in 2 o più server

score 1 · Answer 1

Should I have separate class for each of different client categories (probably overkill), or should I have only 2 classes ClientCategory1 and ClientCategory2to10?

Nessuno dei due. Utilizza il modello di strategia :

Quando si crea un utente (probabilmente nel costruttore) e quando si carica un utente dal DB (nel caso in cui il proprio OR / M abbia un tipo di richiamata onLoad) impostare la strategia:

(pseudo-codice)

class User
   private UserCategory category
   private PaymentStrategy paymentStrategy

   constructor
      setStrategyAccordingToCategory()

   @OnEntityLoaded
   public onLoad
      setStrategyAccordingToCategory()

   private setStrategyAccordingToCategory
      if (this.category == Category1)
          paymentStrategy = new AllInclusivePaymentStrategy(this) // cat1 users get everything all-inclusive
      else
          paymentStrategy = new DefaultPaymentStrategy(this) // cat2-10 pay regularily

   public onPayment
      this.paymentStrategy.onPayment

EDIT: Lo pseudo-codice che ho postato è in realtà un cattivo esempio. La decisione sulla strategia di pagamento non dovrebbe essere presa dall'utente stesso ma piuttosto dal servizio di pagamento. Ma hai capito il punto, vero?

score 0 · Answer 2

No, presto ti ritroverai con un numero infinito di classi.

Considera che il tuo oggetto Cliente può avere più di un tipo di categoria. (Sarebbe davvero più facile se le persone usassero esempi reali). Usiamo gli animali

Skin : Furry, hairy, bald, scaley.. etc
Mobility : Running, Jumping, Flying.. etc

Quindi ora ho SkinTypes * MobilityTypes numero di possibili classi

score 0 · Answer 3

In base al tuo esempio, consiglierei il modo orientato agli oggetti: avere classi diverse per questi due tipi di client.

Un'altra possibilità che non hai menzionato è di rielaborare il design. Probabilmente client può rimanere ed è necessario introdurre ClientCategory che ha 2 implementazioni al momento.

Ma l'esempio è molto superficiale e nella mia esperienza è necessario decidere caso per caso.