Differenza tra le specifiche e una politica?

Question

Sto leggendo il brillante libro "Domain Driven Design" scritto da Eric Evans. Nel suo libro, Eric descrive due concetti diversi: il modello e le politiche delle specifiche.

Ecco un esempio per una specifica:

public interface ProjectSpecification { 
    public boolean isSatisfiedBy(Project p); 
} 

public class ProjectIsOverdueSpecification implements ProjectSpecification { 
    public boolean isSatisfiedBy(Project p) { … } 
} 

//client: 
if { 
    (projectIsOverdueSpecification.isSatisfiedBy(theCurrentProject) { … } 
} 

Ecco un esempio di una politica:

public class CargoBooking { 

    private OverBookingPolicy overBookingPolicy = new OverBookingPolicy(); 

    public int makeBooking(Cargo cargo, Voyage voyage) { 
    if (!overbookingPolicy.isAllowed(cargo, voyage)) 
     return –1; 
    int confirmation = orderConfirmationSequence.next(); 
    voyage.addCargo(cargo, confirmation); 
    return confirmation; 
    } 
} 

public OverBookingPolicy { 
    public boolean isAllowed(Cargo cargo, Voyage voyage) { 
    return (cargo.size() + voyage.bookedCargoSize()) <= (voyage.capacity() * 1.1); 
    } 
} 

So che una politica è in realtà una strategia, ma nei due esempi sopra riportati ci non fa assolutamente differenza Quindi la mia domanda a questo punto è: qual è la differenza tra questi due modelli? Entrambi i modelli rendono esplicite le regole aziendali, quindi perché distinguere tra questi due modelli? Per me sono entrambi dei predicati.

Answer 1

L'idea principale dietro specifica è che si tratta di un predicato, che spesso implica utilizzando gli operatori logici con esso

SPECIFICHE è un adattamento di un formalismo consolidata (Eric Evans DDD, p. 274)

per esempio possiamo dire che la casella è rossa, cioè soddisfa alcuni RedSpecification. Possiamo dichiarare alcune GreenSpecification e anche una composizione RedOrGreenSpecification. Se abbiamo qualche quadro avanzato che supporta le operazioni logiche per le specifiche può essere qualcosa di simile a

BoxSpecification redBoxSpec = BoxSpecification.forColor(BoxColor.RED); 
BoxSpecification greenBoxSpec = BoxSpecification.forColor(BoxColor.GREEN); 
BoxSpecification redOrGreenBoxSpec = redBoxSpec.or(greenBoxSpec); 

allora possiamo utilizzare la specifica, ad esempio per interrogare tutte le caselle di rosso/verde da qualche repository:

Collection<Box> boxes = boxRepository.findAll(redOrGreenBoxSpec); 

Per quanto riguarda POLICY - è una variante del pattern STRATEGY, ma il suo scopo principale è incapsulare le regole di business è una forma dichiarativa.

Tecnicamente - non è sempre una diretta applicazione della strategia - in primi stadi può essere solo una classe separata (come è mostrato nel primo capitolo del libro blu), ma può essere facilmente esteso in seguito

La politica è un altro nome per il modello di progettazione noto come STRATEGIA È solitamente motivato dalla necessità di sostituire diverse regole, che non è necessario qui, per quanto ne sappiamo. Ma il concetto che stiamo cercando di catturare fornisca la significato di una politica, che è una motivazione altrettanto importante nel dominio-driven-design

Per esempio confezioniamo presenta in scatole gialle nel mese di gennaio, e in rosso scatole di febbraio

public class Box{ 
    public BoxColor getColor(){} 
    public void recolor(BoxColor color){} 
} 

public class BoxFactory{ 
    public Box createDefaultBox(SomeDate date){ 
     NewBoxPolicy boxPolicy = PolicyRegistry.getNewBoxPolicyForDate(date); 
     Box box = new Box(); 
     boxPolicy.prepareBox(box); 
     return box; 
    } 
} 
public interface NewBoxPolicy{ 
    void prepareBox(Box box); 
} 
public class FebruaryNewBoxPolicy implements NewBoxPolicy{ 
    public void prepareBox(Box box) { box.recolor(BoxColor.RED}; } 
} 
public class JanuaryNewBoxPolicy implements NewBoxPolicy{ 
    public void prepareBox(Box box) { box.recolor(BoxColor.YELLOW}; } 
} 
public class PolicyRegistry{ 
    public static NewBoxPolicy getNewBoxPolicyForDate(SomeDate date){ 
     switch (date.month()){ 
     case SomeMonth.JANUARY: return JANUARY_NEW_BOX_POLICY; 
     case SomeMonth.FEBRUARY: return FEBRUARY_NEW_BOX_POLICY; 
     default: throw new AssertionError(); 
     } 
} 

e 'importante capire che la politica può incapsulare le azioni, mentre specifica descrive solo le proprietà di un oggetto (queste proprietà possono soddisfare sia o non soddisfano i requisiti di business). Alcune POLICY di convalida possono utilizzare SPECIFICHE per verificare che i requisiti siano soddisfatti, naturalmente.

Quindi è possibile avere molte diverse istanze di SPECIFICAZIONE nel progetto e possono descrivere sia gli oggetti validi che quelli non validi dal punto di vista aziendale.In realtà, le specifiche non hanno alcun senso: ad esempio se si dispone di un sito di ricerca prodotto, l'utente può specificare una richiesta per cercare un prodotto denominato "XBOX", ma con il nome del venditore "Sony", se la conoscenza che solo il i fornitori specifici possono produrre i prodotti specifici non vengono catturati nel modello.

L'aspetto importante della politica è che il suo intento è quello di incapsulare le effettivi regole di business (in modo che il codice non è sparso le diverse parti del progetto), in modo che quando le regole cambiano si può facilmente trovare la classe corrispondente. Quindi puoi avere molte SPECIFICHE nel tuo progetto, ma un numero gestibile di POLITICHE, e quelle POLITICHE dovrebbero essere facili da trovare e da cambiare.

P.S. per favore nota che questo post è solo un esempio e non una licenza per fare over-engineering, ovviamente dovresti usare il design più semplice possibile, è una questione di buon senso.