仕様とポリシーの違いは？

Question

私はEric Evansによって書かれた華麗な本 "Domain Driven Design"を読んでいます。彼の著書Ericは、仕様パターンとポリシーの2つの異なる概念について説明しています。ここ

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

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

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

は、ポリシーの例である：

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

Iポリシーが実際に戦略であることを知っているが、そこに上記の2つの例でここ

は仕様の一例です違いは全くありません。ですから、私の質問はこの時点でです：これら2つのパターンの違いは何ですか？どちらのパターンでもビジネスルールが明示的になります。なぜこれらの2つのパターンを区別するのでしょうか？私にとっては、どちらも述語の一種です。

Answer 1

仕様の背後にある主なアイデアは、それはしばしば

仕様が確立形式主義の適応であることと論理演算子を使用することを意味述語、ということです（エリック・エヴァンスDDD、P。274）

たとえば、ボックスが赤であると言うことができます。つまり、RedSpecificationを満たしています。いくつかのGreenSpecification、さらには複合的なRedOrGreenSpecificationを宣言することができます。 私たちは仕様のための論理演算をサポートしているいくつかの先進的なフレームワークを持っている場合、それは、我々はいくつかのリポジトリからすべての赤/緑のボックスを照会するために、たとえば仕様を使用することができます

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

ようなものになることができます。

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

POLICYについては、STRATEGYパターンの変形ですが、その主な目的はビジネスルールをカプセル化することです。これは宣言的な形式です。

技術 - （それは青本の最初の章で示していますよう）最初の段階でそれだけで別のクラスすることができますが、それは後から簡単に

拡張することができます - それは、常に戦略の直接的な実装ではありません

ポリシーは、戦略として知られているデザインパターンの別の名前です。ここでは必要ではないさまざまなルールを、われわれが知っている限りで置き換える必要があることが通常は意欲的です。しかし、我々は捕獲しようとしている概念は、我々は1月中に、そして赤に黄色のボックスにプレゼントを詰める例えばドメイン駆動設計でも同様に重要な動機である政策のを意味、

に合うんボックスは、2月

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

にそれは仕様のみ（これらのプロパティを満たすことができるの両方またはビジネス要件を満たしていない）オブジェクトのプロパティを説明しながら、そのポリシーは、アクションをカプセル化することができます理解することが重要です。いくつかのバリデーションポリシーでは、要件が満たされているかどうかを確認するためにSPECIFICATIONを使用できます。

したがって、プロジェクトには多くの異なるSPECIFICATIONインスタンスを持つことができ、ビジネス観点から有効オブジェクトと無効オブジェクトの両方を記述することができます。実際には、仕様は全く意味をなさないことがあります。たとえば、製品検索サイトがある場合、「XBOX」という名前の製品を検索する要求を指定できますが、ベンダ名が「Sony」の場合、特定のベンダーが特定の製品を生産できるかどうかは、お客様のモデルには反映されません。

政策の重要な側面は、その意図は実際ビジネスルールをカプセル化することであるということである（そのコードは、プロジェクトのさまざまな部分を散乱されない）ので、ルールが変更されたとき、あなたは簡単に対応するクラスを見つけることができます。したがって、あなたのプロジェクトには多くのスペックを持たせることができますが、管理可能な数のポリシー、およびそれらのポリシーは簡単に見つけて変更する必要があります。

P.S.この記事は単なる例であり、オーバーエンジニアリングを行うためのライセンスではないことに注意してください。もちろん、可能な限りシンプルなデザインを使用する必要があります。これは常識の問題です。