proliferazione di classe in un'applicazione Java DDD

Question

proliferazione di classe in un'applicazione Java DDD

#1 da (3 voti)

1

Ho letto un po 'di DDD da quando mi sono imbattuto in un'applicazione web, presumibilmente scritta secondo i principi del DDD.

Alcune cose che vedo però in questa applicazione mi sembrano totalmente assurde. Come ho capito, il punto principale del DDD riguarda il "linguaggio ubiquitario" condiviso da analisti e sviluppatori, in modo tale che gli artefatti del software corrispondono approssimativamente alle nozioni / nomi / verbi / ... nel "linguaggio ubiquitario". Ciò dovrebbe consentire una traduzione più rapida dei requisiti degli analisti in un software funzionante, dal momento che, ancora una volta, si deve pensare meno a come modellare i requisiti degli analisti e la manutenzione è più semplice.

Tuttavia quello che vedo nell'applicazione web che ho trovato è che, ad esempio, cosa sarebbe altrimenti modellato da una semplice enumerazione, come

public enum Car{
  AUDI,
  BMW,
  VOLVO
}

è modellato nel codice da tre classi diverse Audi, Bmw, Volvo. Allo stesso modo, chiama essenzialmente lo stesso servizio, ad es. CarService.buy(Car car) , con diversi valori di parametri, sono fatti definendo una classe separata per ognuna di queste chiamate di servizio, AudiService.buy() , BmwService.buy() , VolvoService.buy() .

Questo è un modo tipico di scrivere applicazioni DDD?

domain-driven-design java

posta John Donn 04.09.2017 - 12:24

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design java

Ottimizza le ricerche non banali nel vettore di puntatori di oggetti che condividono la classe base Compatibilità Windows con Unix / Linux newline "\ n"

score 3 · Answer 1

Is this a typical way to write DDD applications?

No, ma forse.

Hai assolutamente ragione che normalmente non creiamo una classe, o un sistema di classe, per ogni valore di una proprietà. Nella maggior parte delle implementazioni, qualcosa come una macchina prodotta sarebbe trattata come un'etichetta opaca, senza distinzione di comportamento basata sul valore dell'etichetta.

Quindi normalmente mi aspetto un'implementazione del tipo:

class Make {
    public final String name;

    boolean IsEqual(Make that) {
        return this.name.equals(that.name);
    }
}

Tu potresti usare un peso mosca, piuttosto che un involucro attorno a una primitiva, per i casi in cui l'intervallo di valori è ben compreso e improbabile che cambi in breve tempo.

Ma ... parte del punto è di adattare il modello di dominio alle esigenze del business specifico. Il fatto che Make sia un valore opaco nel mio dominio non significa che sia un valore opaco in tutti i domini.

Classi separate per Audi, BMW e Volvo sarebbero certe nel caso in cui ognuna di quelle marche stesse monitorando lo stato diverso , o avesse regole diverse su come i dati potrebbero cambiare nel tempo.

It just looks like someone said "ok, since it is a DDD application, let's model with class hierarchies what would be otherwise modelled with enumerations".

final class BMW extends Make {
    BMW () {
        super("BMW");
    }
}

Non è sbagliato, ma sembra strano ; Non mi aspetto di vedere questo genere di cose nel modello di dominio senza alcune prove aggiuntive della sua necessità.

Un luogo in cui potresti vedere qualcosa di simile è quello in cui ti stai appoggiando al sistema di tipi per garantire la correttezza di più parti interagenti.

class ExchangeService<M extends Model<M>> {
    void swap(M lhs, M rhs);
}

class BMW extends Model<BMW> {...}
class Audi extends Model<Audi> {...}

void example(ExchangeService<BMW> exchange ) {
    // COMPILE TIME ERROR
    exchange.swap(new BMW(), new Audi());
}