Sự khác biệt giữa đặc điểm kỹ thuật và chính sách?

Question

Tôi đang đọc cuốn sách tuyệt vời "Thiết kế điều khiển miền" được viết bởi Eric Evans. Trong cuốn sách của ông Eric mô tả hai khái niệm khác nhau: mô hình và chính sách đặc điểm kỹ thuật.

Dưới đây là một ví dụ cho một đặc điểm kỹ thuật:

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

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

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

Dưới đây là một ví dụ cho một chính sách:

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

Tôi biết rằng một chính sách thực sự là một chiến lược nhưng trong hai ví dụ trên có hoàn toàn không có sự khác biệt. Vì vậy, câu hỏi của tôi vào thời điểm này là: Sự khác biệt giữa hai mẫu đó là gì? Cả hai mẫu đều làm cho các quy tắc kinh doanh rõ ràng, vậy tại sao chúng ta phân biệt giữa hai mẫu đó? Đối với tôi cả hai đều là loại vị ngữ.

Answer 1

Ý tưởng chính đằng sau QUY CÁCH là nó là một vị ngữ, mà thường ngụ ý sử dụng toán tử logic với nó

ĐẶC TÍNH KỸ THUẬT là một sự thích nghi của một hình thức thành lập (Eric Evans DDD, p. 274)

Ví dụ:

ví dụ: chúng tôi có thể nói rằng hộp có màu đỏ, nghĩa là thỏa mãn một số tính năng RedSpecification. Chúng ta có thể khai báo một số GreenSpecification, và thậm chí cả một RedOrGreenSpecification tổng hợp. Nếu chúng ta có một số khuôn khổ tiên tiến hỗ trợ các hoạt động hợp lý cho thông số kỹ thuật nó có thể là một cái gì đó giống như

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

sau đó chúng ta có thể sử dụng các đặc điểm kỹ thuật ví dụ để truy vấn tất cả/hộp xanh đỏ từ một số kho:

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

Đối với CHÍNH SÁCH - đó là một biến thể của mô hình STRATEGY, nhưng mục đích chính của nó là đóng gói các quy tắc kinh doanh là một số hình thức khai báo.

Về mặt kỹ thuật - nó không phải luôn luôn là một chỉ đạo thực hiện Chiến lược - trong giai đoạn đầu, nó có thể chỉ là một lớp riêng biệt (như được hiển thị trong chương đầu tiên của cuốn sách màu xanh), nhưng nó có thể dễ dàng mở rộng sau

Chính sách là tên khác cho mẫu thiết kế được gọi là CHIẾN LƯỢC Nó thường được thúc đẩy bởi sự cần thiết phải thay thế các quy tắc khác nhau, điều này không cần thiết ở đây, như chúng ta đã biết. Nhưng khái niệm này, chúng tôi đang cố gắng chụp không phù hợp với những nghĩa của một chính sách, mà là một động lực quan trọng không kém trong phạm vi-driven-thiết kế

Ví dụ chúng tôi gói quà trong hộp vàng vào tháng Giêng, và màu đỏ các hộp trong tháng 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(); 
     } 
} 

Điều quan trọng là phải hiểu rõ các thuộc tính của đối tượng (các thuộc tính này có thể thỏa mãn hoặc KHÔNG đáp ứng các yêu cầu kinh doanh). Một số CHÍNH SÁCH xác nhận có thể sử dụng ĐẶC ĐIỂM để kiểm tra xem các yêu cầu có được đáp ứng hay không, tất nhiên.

Vì vậy, bạn có thể có nhiều cá thể THÔNG SỐ khác nhau trong dự án của mình và chúng có thể mô tả cả đối tượng hợp lệ và không hợp lệ từ quan điểm kinh doanh.Trên thực tế, thông số kỹ thuật có thể không có ý nghĩa gì cả: ví dụ: nếu bạn có trang web tìm kiếm sản phẩm, người dùng có thể chỉ định yêu cầu tìm kiếm sản phẩm có tên "XBOX", nhưng với tên nhà cung cấp "Sony", nếu kiến ​​thức chỉ các nhà cung cấp cụ thể có thể sản xuất các sản phẩm cụ thể không bị bắt trong mô hình của bạn.

Khía cạnh quan trọng của chính sách là mục đích của nó là để đóng gói các quy tắc kinh doanh thực tế (vì vậy mã không phân tán các phần khác nhau của dự án), vì vậy khi các quy tắc thay đổi bạn có thể dễ dàng tìm thấy những lớp tương ứng. Vì vậy, bạn có thể có nhiều THÔNG SỐ KỸ THUẬT trong dự án của mình, nhưng một số POLICIES có thể quản lý được, và những CHÍNH SÁCH đó phải dễ tìm và thay đổi.

P.S. xin lưu ý rằng bài đăng này chỉ là một ví dụ và không phải là giấy phép để thực hiện kỹ thuật quá mức, tất nhiên bạn nên sử dụng thiết kế đơn giản nhất có thể, đó là vấn đề thông thường.