Unterschied zwischen Spezifikation und Richtlinie?

Question

Ich lese das brillante Buch "Domain Driven Design" von Eric Evans geschrieben. In seinem Buch beschreibt Eric zwei verschiedene Konzepte: das Spezifikationsmuster und die Richtlinien. Hier

ist ein Beispiel für eine Spezifikation:

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

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

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

Hier ist ein Beispiel für eine Politik:

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); 
    } 
} 

Ich weiß, dass eine Politik tatsächlich eine Strategie ist, aber in den beiden oben genannten Beispielen dort ist absolut kein Unterschied. Also meine Frage an dieser Stelle ist: Was ist der Unterschied zwischen diesen beiden Mustern? Beide Muster machen Geschäftsregeln explizit, weshalb unterscheiden wir diese beiden Muster? Für mich sind beide Prädikate.

Answer 1

Die Grundidee hinter Spezifikation ist, dass es ein Prädikat ist, die oft mit ihm

Spezifikation ist eine Adaption eines etablierten Formalismus (Eric Evans DDD, p. 274)

mit logischen Operatoren impliziert

zum Beispiel können wir sagen, dass die Box rot ist, dh einige RedSpecification erfüllt. Wir können einige GreenSpecification und sogar eine Composite RedOrGreenSpecification deklarieren. Wenn wir einige erweiterte Rahmen haben, die logische Operationen für Spezifikationen unterstützt, kann es so etwas wie

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

sein, dann können wir die Spezifikation zum Beispiel verwenden, um alle rot/grün-Boxen von einem Repository abzufragen:

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

Wie bei POLICY - es ist eine Variante von STRATEGY-Muster, aber sein Hauptzweck ist das Verkapseln der Geschäftsregeln ist eine deklarative Form.

Technisch - es ist nicht immer eine direkte Umsetzung der Strategie - in ersten Stadien es nur eine separate Klasse sein kann (wie es im ersten Kapitel des blauen Buchs gezeigt wird), aber es kann später leicht

verlängert werden

Policy ist ein anderer Name für das Designmuster bekannt als STRATEGIE Es wird in der Regel durch die Notwendigkeit motiviert, verschiedene Regeln zu ersetzen, die hier nicht benötigt wird, soweit wir wissen. Aber das Konzept, das wir aufnehmen möchten, paßt die Bedeutung eine Politik, die eine ebenso wichtige Motivation in Domain-driven-design ist

Zum Beispiel wir packen Geschenke in gelben Kästen im Januar, und in rot Boxen in

Februar

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(); 
     } 
} 

Es ist wichtig, dass die Politik zu verstehen, können Aktionen einkapseln, während Spezifikation beschreibt nur die Eigenschaften eines Objektes (diese Eigenschaften erfüllen beide oder nicht die geschäftlichen Anforderungen erfüllen). Einige Validierungsrichtlinien können mit SPECIFICATIONS natürlich überprüfen, ob die Anforderungen erfüllt sind.

So können Sie viele verschiedene SPECIFICATION-Instanzen in Ihrem Projekt haben, und sie können sowohl die gültigen als auch die ungültigen Objekte vom geschäftlichen Standpunkt aus beschreiben.Tatsächlich können Spezifikationen überhaupt keinen Sinn ergeben: Wenn Sie beispielsweise eine Produktsuchseite haben, kann der Benutzer eine Anfrage zur Suche nach einem Produkt namens "XBOX", aber mit dem Herstellernamen "Sony" angeben, wenn das Wissen, dass nur der bestimmte Anbieter können die spezifischen Produkte produzieren, die nicht in Ihrem Modell erfasst werden. Der wichtige Aspekt von POLICY ist, dass die Absicht darin besteht, die tatsächlichen Geschäftsregeln zu verkapseln (also ist der Code nicht die verschiedenen Teile des Projekts verstreut), wenn die Regeln sich ändern, können Sie leicht die entsprechende Klasse finden. Sie können also viele SPEZIFIKATIONEN in Ihrem Projekt haben, aber eine überschaubare Anzahl von POLICIES und diese POLICIES sollten leicht zu finden und zu ändern sein.

P.S. Bitte beachten Sie, dass dieser Post nur ein Beispiel ist und keine Lizenz für Über-Engineering, natürlich sollten Sie das einfachste mögliche Design verwenden, es ist eine Frage des gesunden Menschenverstandes.