Khi nào bạn KHÔNG nên sử dụng Công cụ quy tắc? [đóng cửa]

Tôi có một danh sách khá phong phú về những lợi thế của việc sử dụng Công cụ quy tắc, cũng như một số lý do để sử dụng chúng, những gì tôi cần là danh sách những lý do tại sao bạn KHÔNG nên sử dụng Công cụ quy tắc

Điều tốt nhất tôi có cho đến nay là:

Công cụ quy tắc không thực sự nhằm mục đích xử lý quy trình làm việc hoặc thực thi quy trình cũng không phải là công cụ quy trình công việc hoặc công cụ quản lý quy trình được thiết kế để thực hiện các quy tắc.

Bất kỳ lý do lớn nào khác khiến bạn không nên sử dụng chúng?

Tôi rất lo lắng khi thấy mọi người sử dụng các bộ quy tắc rất lớn (ví dụ: theo thứ tự của hàng nghìn quy tắc trong một bộ quy tắc). Điều này thường xảy ra khi công cụ quy tắc là một đơn vị nằm ở trung tâm của doanh nghiệp với hy vọng rằng việc giữ các quy tắc KHÔ sẽ giúp chúng có thể truy cập được với nhiều ứng dụng yêu cầu chúng. Tôi sẽ bất chấp bất cứ ai để nói với tôi rằng một công cụ quy tắc Rete với nhiều quy tắc đó đã được hiểu rõ. Tôi không biết bất kỳ công cụ nào có thể kiểm tra để đảm bảo rằng xung đột không tồn tại.

Tôi nghĩ rằng các bộ quy tắc phân vùng để giữ chúng nhỏ là một lựa chọn tốt hơn. Các khía cạnh có thể là một cách để chia sẻ một bộ quy tắc chung giữa nhiều đối tượng.

Tôi thích cách tiếp cận đơn giản hơn, theo hướng dữ liệu hơn nếu có thể.

Tôi sẽ đưa ra 2 ví dụ từ kinh nghiệm cá nhân trong đó sử dụng Công cụ quy tắc là một ý tưởng tồi, có thể điều đó sẽ hữu ích: -

1. Trong một dự án trước đây, tôi nhận thấy rằng các tệp quy tắc (dự án sử dụng Drools) chứa rất nhiều mã java, bao gồm các vòng lặp, các hàm, v.v. Về cơ bản, chúng là các tệp java giả mạo như tệp quy tắc. Khi tôi hỏi kiến ​​trúc sư về lý do của anh ấy cho thiết kế, tôi được trả lời rằng "Các quy tắc không bao giờ được dự định duy trì bởi người dùng doanh nghiệp".

Bài học : Chúng được gọi là "Quy tắc kinh doanh" là có lý do, đừng sử dụng các quy tắc khi bạn không thể thiết kế một hệ thống có thể dễ dàng duy trì / hiểu được bởi người dùng Doanh nghiệp.

2. Một trường hợp khác; Dự án đã sử dụng các quy tắc vì các yêu cầu không được xác định / hiểu rõ và thường xuyên thay đổi. Giải pháp của nhóm phát triển là sử dụng rộng rãi các quy tắc để tránh việc triển khai mã thường xuyên.

Bài học : Các yêu cầu có xu hướng thay đổi nhiều trong những lần thay đổi bản phát hành ban đầu và không đảm bảo việc sử dụng các quy tắc. Sử dụng các quy tắc khi doanh nghiệp của bạn thay đổi thường xuyên (không phải yêu cầu). Ví dụ: - Một phần mềm thực hiện thuế của bạn sẽ thay đổi hàng năm khi luật thuế thay đổi và việc sử dụng các quy tắc là một ý tưởng tuyệt vời. Bản phát hành 1.0 của ứng dụng web sẽ thường xuyên thay đổi khi người dùng xác định các yêu cầu mới nhưng sẽ ổn định theo thời gian. Không sử dụng các quy tắc thay thế cho việc triển khai mã. Các bác sĩ cho biết:

Tôi là một fan hâm mộ lớn của Công cụ quy tắc kinh doanh, vì nó có thể giúp bạn làm cho cuộc sống của mình dễ dàng hơn nhiều với tư cách là một lập trình viên. Một trong những kinh nghiệm đầu tiên mà tôi có khi làm việc trong một dự án Kho Dữ liệu là tìm ra các Thủ tục được Lưu trữ chứa các cấu trúc CASE phức tạp trải dài trên toàn bộ các trang. Thật là một cơn ác mộng khi gỡ lỗi, vì rất khó hiểu logic được áp dụng trong các cấu trúc CASE dài như vậy và để xác định xem bạn có trùng lặp giữa quy tắc ở trang 1 của mã và quy tắc khác từ trang 5. Nhìn chung, chúng tôi đã hơn 300 quy tắc như vậy được nhúng trong mã.

Khi chúng tôi nhận được một yêu cầu phát triển mới, đối với thứ gọi là Điểm đến kế toán, liên quan đến việc xử lý hơn 3000 quy tắc, tôi biết phải thay đổi điều gì đó. Hồi đó tôi đang làm việc trên một nguyên mẫu mà sau này trở thành nguyên mẫu của cái mà bây giờ là công cụ Quy tắc nghiệp vụ tùy chỉnh, có khả năng xử lý tất cả các toán tử chuẩn SQL. Ban đầu, chúng tôi sử dụng Excel làm công cụ soạn thảo và sau đó, chúng tôi đã tạo một ứng dụng ASP.net cho phép Người dùng Doanh nghiệp xác định các quy tắc kinh doanh của riêng họ mà không cần viết mã. Bây giờ hệ thống hoạt động tốt, với rất ít lỗi và chứa hơn 7000 quy tắc để tính Đích kế toán này. Tôi không nghĩ rằng kịch bản như vậy có thể xảy ra chỉ bằng cách viết mã cứng.

Tuy nhiên, có những giới hạn đối với cách tiếp cận như vậy:

• Bạn cần có những người dùng doanh nghiệp có năng lực hiểu biết tuyệt vời về hoạt động kinh doanh của công ty.
• Có một khối lượng công việc đáng kể về việc tìm kiếm toàn bộ hệ thống (trong trường hợp của chúng tôi là Kho dữ liệu), để xác định tất cả các điều kiện được mã hóa cứng có ý nghĩa để chuyển thành các quy tắc được xử lý bởi Công cụ quy tắc kinh doanh. Chúng tôi cũng phải cẩn thận để Người dùng Doanh nghiệp có thể hiểu được các mẫu ban đầu này.
• Bạn cần có một ứng dụng được sử dụng để tạo quy tắc, trong đó các thuật toán phát hiện các quy tắc kinh doanh chồng chéo được triển khai. Nếu không, bạn sẽ kết thúc với một mớ hỗn độn lớn, nơi không ai hiểu được kết quả mà họ nhận được. Khi bạn gặp lỗi trong một thành phần chung như Công cụ quy tắc kinh doanh tùy chỉnh, có thể rất khó gỡ lỗi và cần phải kiểm tra sâu rộng để đảm bảo rằng những thứ hoạt động trước đây cũng hoạt động ngay bây giờ.

Bạn có thể tìm thấy thêm chi tiết về chủ đề này trên một bài đăng mà tôi đã viết: http://dwhbp.com/post/2011/10/30/Implecting-a-Business-Rule-Engine.aspx

Nhìn chung, lợi thế lớn nhất của việc sử dụng Công cụ quy tắc kinh doanh là nó cho phép người dùng kiểm soát lại các định nghĩa và tác giả của Quy tắc kinh doanh mà không cần đến bộ phận CNTT mỗi khi họ cần sửa đổi điều gì đó. Nó cũng làm giảm khối lượng công việc đối với các nhóm phát triển CNTT, hiện có thể tập trung vào việc xây dựng những thứ có nhiều giá trị gia tăng hơn.

Chúc mừng,

Nicolae

Một điểm mà tôi nhận thấy là "con dao hai lưỡi" là:

đặt logic trong tay của nhân viên không kỹ thuật

Tôi đã thấy công việc này tuyệt vời, khi bạn có một hoặc hai thiên tài đa ngành ở khía cạnh không kỹ thuật, nhưng tôi cũng đã thấy sự thiếu kỹ thuật dẫn đến cồng kềnh, nhiều lỗi hơn và nói chung là chi phí phát triển / bảo trì gấp 4 lần.

Vì vậy, bạn cần phải xem xét cơ sở người dùng của mình một cách nghiêm túc.

Tôi nghĩ bài viết của Alex Papadimoulis khá sâu sắc: http://thedailywtf.com/articles/soft_coding.aspx

Nó không toàn diện, nhưng anh ấy có một số điểm tốt.

Bài viết TUYỆT VỜI về thời điểm không sử dụng Công cụ quy tắc ... (cũng như khi nào sử dụng công cụ này) ....

http://www.jessrules.com/guidelines.shtml

Một tùy chọn khác là nếu bạn có một bộ quy tắc tuyến tính chỉ áp dụng một lần theo bất kỳ thứ tự nào để đạt được kết quả là tạo một giao diện linh hoạt và nhờ các nhà phát triển viết và triển khai các quy tắc mới này. Ưu điểm là nó rất nhanh vì thông thường bạn sẽ vượt qua phiên ngủ đông HOẶC phiên jdbc cũng như bất kỳ thông số nào để bạn có quyền truy cập vào tất cả dữ liệu ứng dụng của mình nhưng theo cách hiệu quả. Với một danh sách dữ kiện, có thể có rất nhiều vòng lặp / đối sánh thực sự có thể làm chậm hệ thống ..... Đó là một cách khác để tránh một công cụ quy tắc và có thể được triển khai động (vâng, các quy tắc thú vị của chúng tôi đã được triển khai trong một cơ sở dữ liệu và chúng tôi không có đệ quy .... nó hoặc đáp ứng quy tắc hoặc nó không). Nó chỉ là một lựa chọn khác ..... oh và một lợi ích nữa là không phải học cú pháp quy tắc cho các nhà phát triển mới.

Nó thực sự phụ thuộc vào bối cảnh của bạn. Công cụ quy tắc có vị trí của chúng và ở trên chỉ là một tùy chọn khác nếu bạn có các quy tắc về một dự án mà bạn có thể muốn triển khai động cho các tình huống rất đơn giản không yêu cầu công cụ quy tắc.

Về cơ bản, KHÔNG sử dụng công cụ quy tắc nếu bạn có một bộ quy tắc đơn giản và có thể có một giao diện linh hoạt thay vào đó ..... cũng như có thể triển khai động và các nhà phát triển mới tham gia nhóm của bạn có thể học nó nhanh hơn ngôn ngữ drools. (Nhưng đó là ý kiến ​​của tôi)

Theo kinh nghiệm của tôi, các công cụ quy tắc hoạt động tốt nhất khi những điều sau là đúng:

1. Học thuyết được xác định rõ ràng cho miền vấn đề của bạn
2. Dữ liệu chất lượng cao (tốt nhất là tự động) để giúp thúc đẩy hầu hết các đầu vào của bạn
3. Tiếp cận các chuyên gia về chủ đề
4. Nhà phát triển phần mềm có kinh nghiệm tạo hệ thống chuyên gia

Nếu thiếu bất kỳ đặc điểm nào trong số bốn đặc điểm này, bạn vẫn có thể tìm thấy công cụ quy tắc phù hợp với mình, nhưng mỗi lần tôi thử nó mà thậm chí thiếu 1 đặc điểm, tôi lại gặp rắc rối.

Đó chắc chắn là một khởi đầu tốt. Điều khác với các công cụ quy tắc là một số điều được hiểu rõ ràng, xác định và dễ hiểu. Khấu lưu lương là (hoặc sử dụng để được) như vậy. Bạn có thể thể hiện nó dưới dạng các quy tắc sẽ được giải quyết bởi công cụ quy tắc, nhưng bạn có thể biểu thị các quy tắc tương tự như một bảng giá trị khá đơn giản.

Vì vậy, công cụ quy trình làm việc tốt khi bạn thể hiện một quy trình dài hạn hơn sẽ có dữ liệu liên tục. Các công cụ quy tắc có thể làm một điều tương tự, nhưng bạn phải làm rất nhiều thứ phức tạp hơn.

Công cụ quy tắc tốt khi bạn có cơ sở kiến ​​thức phức tạp và cần tìm kiếm. Các công cụ quy tắc có thể giải quyết các vấn đề phức tạp và có thể nhanh chóng thích nghi với các tình huống thay đổi, nhưng áp đặt rất nhiều phức tạp cho việc triển khai cơ sở.

Nhiều thuật toán quyết định đủ đơn giản để thể hiện như một chương trình hướng bảng đơn giản mà không có độ phức tạp như một công cụ quy tắc thực.

Tôi thực sự khuyên bạn nên sử dụng các công cụ quy tắc kinh doanh như Drools dưới dạng mã nguồn mở hoặc Công cụ quy tắc thương mại như LiveRules.

• Khi bạn có nhiều chính sách kinh doanh có tính chất bất ổn, bạn sẽ rất khó duy trì phần mã công nghệ cốt lõi đó.
• Công cụ quy tắc cung cấp tính linh hoạt tuyệt vời của khung và dễ dàng thay đổi và triển khai.
• Công cụ quy tắc không được sử dụng ở mọi nơi mà cần được sử dụng khi bạn có nhiều chính sách mà những thay đổi là không thể tránh khỏi thường xuyên.

Tôi không thực sự hiểu một số điểm như:
a) người kinh doanh cần phải hiểu rất rõ về kinh doanh, hoặc;
b) bất đồng về doanh nhân không cần biết quy tắc.

Đối với tôi, là một người chỉ chạm vào BRE - lợi ích của BRE được gọi là để hệ thống thích ứng với sự thay đổi của doanh nghiệp, do đó nó tập trung vào việc thích ứng với sự thay đổi.
Có vấn đề gì không nếu quy tắc được thiết lập tại thời điểm x khác với quy tắc được thiết lập tại thời điểm y vì:
a) người kinh doanh không hiểu về kinh doanh, hoặc;
b) người kinh doanh không hiểu quy tắc?