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

私はアプリケーションを構築することを検討しています。そのアプリケーションのコアは、数千のif ... then ... elseステートメントで構成されます。このアプリケーションの目的は、あらゆる風景で牛がどのように動き回るかを予測できるようにすることです。彼らは太陽、風、食物源、突然の出来事などの影響を受けます。 このようなアプリケーションはどのように管理できますか？数百のIFステートメントの後、プログラムがどのように反応するかは予測不可能であり、特定の反応につながることをデバッグすると、毎回IFステートメントツリー全体を走査する必要があることを意味すると思います。 ルールエンジンについて少し読みましたが、この複雑さをどのように回避できるかわかりません。

214 design  design-patterns  business-rules  prolog  logic-programming 

私は、ほとんどのビジネスロジックがデータベースに実装されているプロジェクト（主にストアドプロシージャを使用）で働いてきました。一方、仲間のプログラマーからは、これは悪い習慣だと聞いたことがあります（「データベースはデータを保存するためにあります。アプリケーションは残りを行うためにあります」）。 これらのアプローチのどれが一般的に優れていますか？ 私が考えることができるDBにビジネスロジックを実装することの長所は次のとおりです。 ビジネスロジックの集中化。 アプリケーションの種類、プログラミング言語、OSなどの独立性。 データベースは、テクノロジーの移行や大きなリファクタリング（AFAIK）を受けにくい傾向があります。 アプリケーションテクノロジの移行に関する手直しはありません（例：.NETからJava、PerlからPythonなど）。 短所： SQLは、ほとんどのアプリケーション指向言語が提供するライブラリと言語構成の欠如により、ビジネスロジックプログラミングの生産性が低く、より複雑です。 ライブラリ経由でのコードの再利用がより困難です（可能な場合）。 生産性の低いIDE。 注：私が話しているデータベースは、SQL Server、Oracle、MySqlなどのリレーショナルで人気のあるデータベースです。 ありがとう！

107 database  application-design  business-logic  business-rules 

職場やオンラインでビジネスロジックについて多くの人が話しているのを聞いたことがあり、このサイトに関するいくつかの質問を読んだことがありますが、この用語はまだあまり意味がありません。たとえば、私がよく見かける（言い換え）ステートメントは次のとおりです。 「ビジネスロジックは、実際のビジネスルールをエンコードするプログラムの一部です。」私が読んだ定義のほとんどは、このような円形のものです。 「ビジネスロジックは、特定のアプリケーションに固有のすべてです。」「特定のアプリケーションはビジネスロジック以外の何物でもない」と、これがどのように異なるかはわかりません。したがって、質問のタイトル。 「データアクセス層の上とGUI層の下にビジネスロジック層が必要です。」私が書いたコードでは、データベースアクセサーはアクセスするデータを知る必要があり、UIコードはそれを正しく表示するために表示するものについて多くを知る必要があり、その間に実際に行うことは何もありませんクライアントとサーバー間でデータの塊を渡すこと以外の2つの場所。それでは、実際にビジネスロジックレイヤーに入るものは何でしょうか？ 「ビジネスロジックはプレゼンテーションロジックから分離する必要があります。」私たちが受け取る機能要求のほとんどは、ビジネス上の理由でプレゼンテーションロジックを変更することです。ビジネスルールの1つが、デフォルトで32番目の表記で米国国債の価格を表示する場合（ユーザーに構成するためのUIも提供します）、プレゼンテーションロジックは、このルールが完全に実装されていない場合、少なくとも存在することを知る必要があります。また、UXデザインの主要な部分は、ユーザーがソフトウェアが実装しようとしているビジネスルールを理解するのを支援しているようです。 実際にビジネスロジックのみを行うチームに所属していて、非ビジネスロジックはすべて他のチームによって実行されている可能性はありますか？または、個別のエンティティとしての「ビジネスロジック」の概念全体は、特定のアプリケーションまたはアーキテクチャでのみ機能しますか？ 答えを具体的にするために：ドミノのピザアプリを再実装する必要があると仮定します。ビジネスロジックとは何ですか？また、そのアプリの非ビジネスロジックとは何ですか？そして、ピザ情報のほとんどがデータアクセス層とプレゼンテーション層に流出することなく、ピザの注文ビジネスロジックを独自のコードの「層」に配置するにはどうすればよいでしょうか。 更新：私のチームはおそらく90％のUIコードを実行しており、ビジネスロジックと呼ばれるものの大部分（すべてではない）が他のチームまたは企業から来ているという結論に達しました。基本的に、私たちのアプリケーションは監視用です財務データ、およびほとんどすべての機能は、ユーザーが表示するデータと表示方法をカスタマイズする方法です。売買は行われていません（ただし、当社の他のアプリと少し統合しています）が、実際のデータは外部ソースの負荷によって提供されます。しかし、ユーザーは自分の「モニター」のコピーを他のユーザーに送信するなどのことを許可しているので、私たちがそれをどのように処理するかの詳細は、おそらくビジネスロジックとみなされます。実際には、現在バックエンドコードの一部と通信するモバイルアプリがあり、フロントエンドコードのどの部分を理想的な世界（基本的には準MVCのM）でUIと共有したいかを正確に知っています。それが私たちにとってのBLLだと思います。 user61852の答えは、「ビジネスロジック」が何を参照し、何を参照していないかについて、より具体的な理解を与えてくれたので受け入れています。

25 architecture  business-logic  business-rules 

象徴的な「Given-When-Then」シナリオ構文を使用した動作駆動型開発は、ソフトウェア機能評価の境界オブジェクトとして使用できる可能性があるため、最近非常に誇張されています。 Gherkin、またはどちらの機能定義スクリプトでも、ビジネスで読み取り可能な DSLであり、すでにそのような価値を提供していることは間違いありません。 ただし、プログラマではない人が書き込み可能であることに同意しません（Martin Fowlerも同様です）。 プログラマ以外の人が作成し、開発者がインスツルメントしたシナリオのアカウントを持っている人はいますか？ 書き込み可能性の欠如についてコンセンサスがある場合、シナリオを開始してそれらをインストルメント化する代わりに、実際のテストからビジネスで読み取り可能なシナリオを生成するツールに問題がありますか？ 更新：「シナリオジェネレータ」ツールに関しては、もちろんビジネス言語を魔法のように推測することはありません;）しかし、現在、正規表現マッチャーを使用して（抽象化次元で）トップダウンアプローチでテストを作成するように、ボトムアップアプローチでシナリオを作成する文字列ビルダー。 「アイデアのみを提供する」例： Given I am on page ${test.currentPage.name} And I click on element ${test.currentAction.element} …

24 documentation  bdd  documentation-generation  business-rules 

私はプログラミングに多少慣れており（私は貿易で機械エンジニアです）、ダウンタイム中に工場周辺のさまざまな人々からの入力に基づいて（solidworks）パーツを生成する小さなプログラムを開発しています。 わずかな入力（正確には6つ）に基づいて、それぞれ最大12個のパラメーターを取ることができる何百ものAPI呼び出しを行う必要があります。すべては、パーツを処理するすべての人にインタビューした後に収集した一連のルールによって生成されます。私のコードのルールとパラメーターのセクションは250行で、成長しています。 だから、コードを読みやすく管理しやすくする最良の方法は何ですか？すべてのマジックナンバー、すべてのルール、アルゴリズム、およびコードの手続き部分をどのように区分するのですか？非常に詳細で詳細なAPIに対処するにはどうすればよいですか？ 私の主な目標は、誰かに私の情報源を渡して、私の入力なしで、私がやっていることを彼らに理解させることです。

21 api  readability  business-rules 

これは私がSOに戻ってしばらく尋ねた質問ですが、ここでよりよく議論されるかもしれません... 私が働いているところで、私たちは何度もこの主題について行き来しており、健全性チェックを探しています。ここに質問があります：ビジネスオブジェクトはデータコンテナ（DTOに似ています）であるか、またはそのオブジェクトでいくつかの機能を実行できるロジックも含まれている必要があります。 例-顧客オブジェクトを取得します。おそらく、いくつかの一般的なプロパティ（名前、IDなど）が含まれますが、その顧客オブジェクトには関数（保存、計算など）も含める必要がありますか？ 1行の推論では、オブジェクトを機能（単一責任プリンシパル）から分離し、ビジネスロジックレイヤーまたはオブジェクトに機能を配置します。 もう一方の推論では、いいえ、顧客オブジェクトがある場合は、Customer.Saveを呼び出して終了します。オブジェクトを消費している場合、顧客を救うために別のクラスについて知る必要があるのはなぜですか？ 私たちの最後の2つのプロジェクトでは、機能からオブジェクトが分離されていましたが、新しいプロジェクトで議論が再び行われました。 どちらがより理にかなっており、なぜですか？

19 business-logic  business-rules 

私はそれが高価であることを知っていますが、（IMO）それは非常に良い習慣だと思います。たとえば、営業担当者でない場合は請求書を保存できないなどのルールについて話しているので、その場合は「あなたは許可されていません」などの例外をスローします... 別のアプローチは、ステータスなどのオブジェクトを持つことです 他のアプローチはありますか？それについてどう思いますか？

16 idioms  business-logic  business-rules  rules-and-constraints 

現在の状況 私たちは、マイクロサービスアーキテクチャでオンラインショッピングWebアプリケーションを実装しています（そして現在保守しています）。 要件の1つは、エクスペリエンスと最終的な注文をカスタマイズするために、顧客がカートに追加するものにルールを適用できる必要があることです。明らかに、ビジネスルールエンジンを導入する必要があり、このために特定の「マイクロサービス」を実装しました（まだそう呼べる場合）。 1年の間に、このルールエンジンはますます複雑になり、より多くのデータ（カートのコンテンツだけでなく、ユーザー情報、役割、既存のサービス、請求情報など）が必要になりました。それらのルールを計算します。 現時点では、shopping-cartマイクロサービスは他のマイクロサービスからこのデータをすべて収集しています。このデータの一部はで使用されますがshopping-cart、ほとんどの場合、主にルールエンジンのフィードに使用されます。 新しい要件 これで、同様の要件にルールエンジンを再利用する他のアプリケーション/マイクロサービスが必要になりました。したがって、現在の状況では、ルールエンジンを呼び出すことができるように、同じ種類のデータを送信し、同じマイクロサービスを呼び出し、（ほぼ）同じリソースを構築する必要があります。 そのまま続行すると、いくつかの問題に直面します。 誰もが（ルールエンジンを呼び出して）データのフェッチを再実装する必要があります（自分でデータを必要としない場合でも）。 ルールエンジンへの要求は複雑です。 この方向で続けると、多くの要求のためにこのデータをネットワーク全体に転送する必要があります（μsAがルールエンジンを呼び出すμsBを考えますが、Aはルールエンジンが必要とするデータの一部を既に持っています）。 shopping-cart すべてのデータ取得により巨大になりました。 おそらく多くのことを忘れてしまいます… これらのトラブルを回避するために何ができますか？ 理想的には、ルールエンジンの複雑さを増やさないようにします。また、ボトルネックにならないように確認する必要があります。たとえば、一部のデータはフェッチに時間がかかります（10秒以上）ためshopping-cart、ルールを呼び出す前にデータが存在する可能性が高くなるようにプリフェッチを実装しましたエンジン、および許容できるユーザーエクスペリエンスを維持します。 いくつかのアイデア ルールエンジンに必要なデータをフェッチさせます。これにより、さらに複雑さが増し、単一の責任原則に違反します（さらに…）。 ルールエンジンがデータを取得する前にプロキシμsを実装します。 ルールエンジンが必要なすべてのデータを一度にフェッチするために呼び出す「データフェッチャー」μsを実装します（複合照会）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

ビジネスルールを文書化する正式で最も一般的に行われている方法は何でしょうか。また、開発成果物のUI仕様をどのように文書化しますか（例：フォームフィールドの文書化、ボタンがフォーム上でどのように動作するか、情報テキストなど）。

12 documentation  business-rules 

私はクリーンについて研究しており、その結果、ソフトウェアの設計と作成の方法について、かなり劇的に再考しています。 しかし、私がまだ取り組んでいることは、「一部のアイテムへの更新の保存時、最初の読み込みなど、表示/編集する権限のあるアイテムのすべてのリスト、このアイテムがリストにあることを確認するなどのビジネスルールです。そして、アイテムカテゴリは現在使用できないようにロックされていません（および他のルールなど） "。それは（複雑だが非定型ではない）ビジネスルールであり、ビジネスロジックをプッシュするのではなく、アプリケーションドメインで処理する必要があるためdb / persistenceレイヤー。 ただし、これらの条件を効率的にチェックするには、すべてのデータをアプリケーションドメインにロードするのではなく、巧妙に作成されたdbクエリで処理するのが最善のようです... 時期尚早な最適化なしで、推奨されるアプローチまたはこの質問を扱っているボブおじさんの記事は何ですか？または、「問題になるまでドメインで検証する」と言いますか？ 最も基本的な使用例以外の良い例やサンプルを見つけるのに苦労しています。 更新： みなさん、こんにちは。返信ありがとうございます。私はもっ​​と明確で、長い間（主にWebアプリ）のソフトウェアを書いていて、まとめて記述したすべてのトピックを確実に経験して同意しているはずです（バックエンドで検証し、クライアントデータを信頼せず、一般的に言って）必要な場合にのみ生の効率を追跡しますが、利用可能な場合はdbツールの強みなどを認識し、「まとめて投げる」という開発者の学習ライフサイクルを経て「N層アプリケーションで巨大な脂肪コントローラーを構築する」コードのトレンド、そして今は基本的にクリーンで単一の責任のスタイルなどを非常に気に入って調査しています。最近のいくつかのプロジェクトの結果として、プロジェクトが進化し、クライアントの要件がさらに明らかになるにつれて、非常に不格好で広く分散したビジネスルールに発展しました。 特に、クライアント向けのREST APIと内部使用機能のためのREST APIを構築するコンテキストでクリーンスタイルアーキテクチャを検討しています。この場合、ビジネスルールの多くは、ネットで目にするすべての例よりもはるかに複雑になる可能性があります。（Clean / Hexアーキテクチャの開発者自身によっても）。 だから私は、CleanとREST APIがどのように共存するかについて本当に質問しました（そして明確に述べられなかった）と思います、ここで最近見られるほとんどのMVCには受信リクエストバリデーターがあります（たとえば。 「検証」ルールはそれほど「50文字未満の文字列ですか」ではなく、「このユーザーは、このユーザーケース/インタラクターを呼び出して、関連するオブジェクトが現在チームXによってロックされている場合、このデータのコレクションに対してこの操作を実行できますか？」月末までなど」...ビジネスドメインオブジェクトやドメインルールが多数適用される、非常に複雑な検証。 これらのルールを特定の種類のValidatorオブジェクトタイプにスピンアウトして、各ユースケースインタラクター（FluentValidatorプロジェクトからインスピレーションを得たものの、より多くのビジネスロジックとデータアクセスを伴う）に付随させる必要があります。それらの検証をゲートウェイ（間違っていると思います）などに配置します。 参考までに、このようないくつかの記事を書きますが、Mattiaは検証についてあまり説明していません。 しかし、私の質問への短い答えは、私が受け入れた答えに非常に似ていると思います：「それは決して簡単なことではなく、それは依存します」。

12 clean-code  domain-model  validation  business-rules 

私はしばらくの間開発者でした。私はそこから最高とはほど遠い。（私はこの部屋に一人で座っているので、私はここで最高かどうか疑問に思います。）しかし、私は自分の道具を理解するようになり、理性と学びの能力に信頼するようになりました。 新しい仕事を始めるとき、私が知っている言語であればコードベースを学ぶことができるといつも信じています。私が知っている言語やフレームワークではない場合、それを学ぶのに十分な概念を把握できると信じています（そして、ドキュメントを読むだけです）。これはプログラマーとしてのスキルセットの一部であり、この標準に対応できることを誇りに思っています。 しかし、これらすべてのために-私の大きな弱点の1つは、私が仕事をしているクライアントのビジネスルールを短期間で学習し、内部化することです。コードベースには問題ありませんが、特定のビジネスのビジネスルールとプロセスは、完全に理解するのに常に時間がかかるようです。（例として、これはエンタープライズアプリケーションを書き換えるときのトリップアップになります。） 開発者として、ビジネスルールとプロセスを迅速かつ効率的に取り入れる最良の方法は何ですか？主題の専門家でなくても、単にクライアント、会社、またはビジネスで長年の経験を持つことは可能ですか？

11 business-rules 

ユーザーストーリーの迅速で汚い定義： "As a <role>, I want <goal/desire> so that <benefit>" この一般に受け入れられている定義では、ビジネスルール、制約、またはユーザー入力を定義するためのスペースがほとんどありません。 説明のための簡単な例： "As a <librarian>, I want to <register new books> so that <students can find their availability online>" このばかげた例では、本を登録するときに必要なフィールドをどこで定義しますか？どこにでも書かれるべきですか？または、必要なビジネスルールをプロダクトオーナーから口コミとして渡す必要がありますか？

11 business-rules  user-story 

誰もがWindows Workflow FoundationをBusinessRules / Validationエンジンに正常に使用したかどうか、またはこれに関するサンプルコードや記事を知っているかどうか疑問に思っていました。 以前に使用したことがある場合、それについてどう思いますか？他のBusinessRule / Validationシステムと比較してどうですか？ 私は次のようなルールを考えています if (A, B, and C) AllowAccess(); または if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 4年前休業。 私がstackoverflowについて同じ質問をしたが、彼らはここで尋ねるように指示したことに注意してください。 アプリケーションロジックとビジネスロジックの違いを識別しようとしていますが、一連の記事を見つけましたが、残念ながらそれらには矛盾があります。 ここ では彼らは同じであると言いますが、ここでの答えはまったく異なります。 私には次のように理解しています。 LogicGoogleで単語の定義を調べると、 特定のタスクを実行するためのコンピューターまたは電子デバイスの要素の配置の基礎となるシステムまたは一連の原則。 したがって、ロジックがその場合、set of principles underlying the arrangements of elementsビジネスロジックはであるset of principles underlying the arrangements of the business rules必要があります。つまり、システムを取得するために従うべきルールがビジネスニーズを反映していることを意味します。 そして、私にとってのアプリケーションロジックはthe principles that the application based on、言い換えると、これらのルールを適用してシステムにビジネスニーズを反映させる方法です。たとえば、MVCを使用すべきか、使用すべきでないか、SQLまたはMSSQlを使用すべきかなどです。 ですから、アプリケーションとビジネスロジックの違いに関する混乱を取り除くために誰かが私を助けていただけませんか。

11 business-logic  business-rules 

多くの場合、私のビジネスオブジェクトは、情報がオブジェクトの境界を頻繁に越える必要がある状況にあります。オブジェクト指向を実行するときは、情報を1つのオブジェクトに入れ、その情報を処理するすべてのコードをできるだけそのオブジェクトに含める必要があります。ただし、ビジネスルールはこの原則に従っていないため、問題が発生します。 例として、価格を持つInventoryItemを参照するOrderItemの数を持つOrderがあるとします。数量をInventoryItem.GetPrice（）で乗算するOrderItem.GetPrice（）の結果を合計するOrder.GetTotal（）を呼び出します。ここまでは順調ですね。 しかし、その後、一部の商品が2対1で販売されていることがわかりました。OrderItem.GetPrice（）にInventoryItem.GetPrice（quantity）のような処理を行わせ、InventoryItemにこれを処理させることで、これを処理できます。 ただし、2対1の取引は特定の期間のみ続くことがわかります。この期間は、注文の日付に基づく必要があります。次にOrderItem.GetPrice（）をInventoryItem.GetPrice（quatity、order.GetDate（））に変更します。 ただし、お客様がシステムに滞在している期間に応じて、さまざまな価格をサポートする必要があります。 しかし、2対1の取引は、同じ在庫アイテムを複数購入するだけでなく、InventoryCategory内のアイテムの複数購入にも適用されることがわかります。この時点で、私たちは手を挙げて、InventoryItemに注文アイテムを与え、それがアクセサーを介してオブジェクト参照グラフ上を移動できるようにし、必要な情報を取得します：InventoryItem.GetPrice（this） TL; DRオブジェクトの結合を低くしたいのですが、ビジネスルールでは、特定の決定を行うために、多くの場合、どこからでも情報にアクセスする必要があります。 これに対処するための良いテクニックはありますか？他の人が同じ問題を見つけますか？

10 design  object-oriented  business-rules