0

データベースのコンテキストでは、 「顧客名が空ではない」または「顧客の購入数が正である」などのステートメントに対して値をチェックする必要がある場合があります...

しかし、そのような声明はルールやポリシーを構成するのでしょうか?

一般的に、これらの概念、それらの違い、および関係をどのように定義しますか?

前もって感謝します。

4

2 に答える 2

1

私はあなたが何について話しているのか知っていると思います。私は以前にそのような区別に遭遇しました（英語の単語はそれほど違いはありませんが）。これがほとんどのビジネスコンピューティング分野でどのように機能すると思うかです。

このようなコンテキストでのルールは、構造的な事実であろうとビジネスに課せられたステートメントであろうと、変更されないか、少なくとも変更される可能性はごくわずかです。「Xをnullにすることはできません」という形式のほとんどのステートメントはルールを表します。「ヌル」は通常、ビジネスユーザーにはあまり意味がありません。通常、モデルの構築方法を調べることで、これらのルールに到達します。ルールを変更すると、データベースとそれをサポートするアプリケーションの構築方法に広範囲にわたる影響があります。

ポリシーは、ビジネスの指示に似ています。優先顧客が10％オフになるのはポリシーかもしれませんが、ご存知のように、このようなことは変わる傾向があります。ポリシーの変更は、アプリケーションの動作に影響を与える可能性がありますが、その基本的なアーキテクチャや基盤には影響しません。

実用的に言えば、ポリシーを比較的簡単に変更できるようにする必要があります。ルールは変更される可能性がありますが、通常はより複雑です。ルールを変更するには、多くの場合、コード、UI、メンタルモデル、考え方などを変更する必要があります。

これがお役に立てば幸いです。

于 2011-01-22T15:55:11.477 に答える
1

データベースのコンテキストでは、ユーザー名を持つことはルールであり、顧客が設定された数よりも少ない割引を顧客に割り当てることを許可するポリシー (管理者またはその他の承認によってオーバーライドされる可能性があります) であると主張します。購入。

Rule: All users must have a username.
Rule: All users must have a password.
Rule: All users must have a valid email address.
Rule: All users must have a valid credit card on file.
Policy: All users begin with a 0% discount rate on purchases.
Policy: All users are required to pay for shipping.

ルールは、検証に裏打ちされた外向きのステートメントです。ポリシーは、結果に裏打ちされた内部ルールです。

後でユーザーがユーザー名を変更できるようにする (ソフトウェアの作成方法によって異なります)、またはサインアップ時に割り当てられた割引率と配送料を調整して、顧客機会を創出するポリシーである可能性があります。

私の推測では、ルールには厳密な検証が必要ですが、ポリシーは本質的に介入や操作の対象となります。

HTH

ジャレド

于 2011-01-22T16:20:26.557 に答える