タグ付けされた質問 「business-rules」

他の人がこれをどのように行っているのか見てみたいです。特に、複数の異なるクライアントが、わずかに異なるビジネスルールで同じソフトウェアベースを使用している状況では。すべてがどのように機能するか、またはビジネスルールを文書化するために、どのような方法を使用していますか。 基本的には、新しい開発者がチームにやって来たときに、バグのないものと適切に機能させることには明らかに違いがあるため、チームがどのように機能するのかを簡単に確認できます。 何かを処理する方法について質問が出るたびにアーキテクトやBSAを会話に参加させる必要はなく、リソースを活用するほうがいいでしょう。

9 documentation  business-rules 

大規模なエンタープライズアプリの場合、変更に対応できることがデザインの最も重要な側面の1つであることは誰もが知っています。ビジネスロジックの変化に対応するために、多くの場合、ルールベースのアプローチを使用しており、各ルールはDBに格納されています。これにより、厄介な詳細に飛び込むことなく、簡単に変更を加えることができます。C＃はEval（ "foo（bar）;"）を実行できないため、これは行に格納されたフォーマットされた文字列を使用して実行され、実行時にJavaScriptで処理されます。これは正常に機能しますが、エレガントではなく、レガシーになると、他の人が手に入れるのが最も楽しいものではありません。 これに対するよりエレガントな解決策はありますか？かなり頻繁に変更される何千ものルールに遭遇すると、それは本当のことになりますが、これは、誰かがこれを行うためのより良い方法を考えていない問題の珍しいことではありません。助言がありますか？この現在の方法は防御可能ですか？代替案は何ですか？ 編集：明確にするために、これは大規模なエンタープライズアプリであるため、どのソリューションが機能しても、ルールとデータ（約10）を常に維持している人はたくさんいます。また、データは頻繁に変更されるため、ある種の集中サーバーシステムは基本的に必須であると言えます。

8 design-patterns  scalability  business-rules  rules-and-constraints