私は現在、ロイヤリティの支払いを管理するシステムをモデル化しています。ロイヤルティは次のように単純です。
- 収益の 15% を著者 A に支払う
または次のいずれかのように複雑です。
- 作成者 B に、売上の 1000 個までは収益の 15%、その後は収益の 12% を支払う
- また、販売数が 1000 までの場合、販売ごとに著者 B に 1.50 ドルを支払う
また:
- 最初の 1,000 ドルの収益について著者 C に収益の 15% を支払い、その後、収益の 12% を支払う
つまり、支払いは、販売ごとの定額または収益のパーセンテージのいずれかです。支払いの条件は、販売数量または収益に基づく場合があります。私は、支払い範囲と支払い値の型を指定することによって、このすべての柔軟性を包含するクラス (舞台裏のデータベース テーブルに密接に対応する) を設計しようとしました。ただし、このクラスでやりすぎて、将来追加のシナリオに対応する必要が生じた場合に追い詰められるのではないかと心配しています。代替設計アプローチの提案を求めています。
public class PaymentRule
{
// I'm not 100% comfortable with this, as this will
// really be an Int32 value for quantity sold ranges
public decimal RangeMinimum { get; set; }
public decimal? RangeMaximum { get; set; }
// This will always be a decimal value, but may represent
// a dollar amount or percentage depending on the context
public decimal PaymentValue { get; set; }
// Specify a type for the range: QuantitySold or Revenue
public string RangeType { get; set; }
// Specify a type for the value: AmountPerEachSold or RevenuePercentage
public decimal ValueType { get; set; }
public decimal CalculateRoyaltyDue(int quantitySold, decimal revenue)
{
// ...
}
}
任意の提案をいただければ幸いです。
2012 年 5 月 9 日更新:
これらのルールは、SQL Server データベースに永続化する必要があることに注意してください。