1

同僚と私は過去2時間話し合っており、顧客の買い物かごを扱う新しいオンラインショップの側面を設計するための最良の方法を模索していますが、私たちが素晴らしい結論。

かなり基本的な問題のように聞こえますが、実際には、システムのさまざまな部分の間に膨大な量の相互依存関係があることがわかりました。

パーツ(これまでのところ!)は次のとおりです。

  • ショッピングバスケット(顧客が購入するために選択した製品を追跡します)。
  • お得な情報(「xを3つ購入して£20」や「xを2つ購入して1つ無料」などの商品のプロモーションを定義します)。
  • 低注文料金(特定の値の下では、追加料金が注文に追加されます)。
  • 配送料(一連のオプションに基づく)。
  • バウチャーの引き換え。
  • 顧客クレジット(顧客は自分のアカウントにクレジットを持っている場合があり、これは注文合計から差し引かれます)。

私は、これらすべてのオブジェクトが相互に通信し、相互に値を取得し、それらの値に基づいて動作することに非常に神経質になっています。私はそれが大きくて複雑でメンテナンス不可能なカードの家になると想像しています。

システムの一部が依存することになるので、システムのさまざまな部分が互いに直接通信することは悪い習慣であると確信しています。他の部分は実行時に異なる状態にあり、それらがすべて互いに通信できる場合、私は何かが私が依存している他の何かを変更していないことを確信できません。

しかし、他の方法で見ることができない例はたくさんあります。例えば:

  • 「Xを購入してYを無料にする」種類の取引では、顧客がバスケットにXを入れてチェックアウトするときに、Y製品をバスケットに追加する必要があります。したがって、取引は効果的に見え、バスケットに影響を与えます。
  • 低注文料金を適用するかどうかの判断は、バスケット内の製品の価値に基づいていますが、複数購入後の割引(たとえば、2の価格で3)。そのため、取引も考慮しながら、バスケットを確認する必要があります。
  • バスケットには、顧客がサイトを閲覧している間も合計値を表示する必要があり、その合計には製品関連の取引が考慮されている必要がありますが、それ以外は考慮されていません。

思いがけない方法で他の多くのコードに影響を与える可能性のあるコードを自分の足で撃ち抜くことなく、どうすればこの種のことを達成できますか?

4

1 に答える 1

0

次の抽象的なエンティティがあるように見えます。

  • バスケット
  • 対処
  • 料金(低注文、送料)
  • クレジット(バウチャー、未払いクレジット)

おそらく、これらの概念を、複数のゲートウェイを使用して具体的なモデルにアクセスする単一のビジネスロジッククラスにラップすることができます。一見すると、ビジネスロジックは、「バスケットに取引を追加し、手数料を適用してから、クレジットオプションを利用する」ように見えます。これらの各コンポーネントは、デコレータのコレクションのように見えます。各デコレータは、バスケットに作用する可能性があります。

ここでのビジネスロジッククラスの仕事は、各ゲートウェイ(Deal、Fee、Credit)を取得し、それらの個々のコンポーネントを反復処理することです。各コンポーネントはバスケットを通過し、影響を与えるかどうかを尋ねられます。バスケットが影響を受ける必要がある場合は、効果を適用して反復を続行できます。

このようにして、ビジネスロジックは、操作の順序を定義する1つの場所に保持されます。各コンポーネントは、ビジネスロジックを介してバスケットに緩く結合されています。

更新可能なアプローチ

于 2012-10-17T19:21:40.563 に答える