title: Using design patterns to model a subscription system
body: <p>Here briefly are the business requirements.</p>
  
  <p>I have an entity called PricingSchedule that represents a "subscription" to a system. We use the term "Pricing Schedule", not "subscription" in our team's ubiquitous language, but in theory, a subscription is the same thing.</p>
  
  <p>What determines the Price of the PricingSchedule is the combination of two things:
  1. the "duration" of the PricingSchedule (aka, how long is your subscription... 1 year, 2 years, etc...
  2. how many Styles (another entity) you want to include in your PricingSchedule. You have two options for how to include Styles; 1. pay per Style, 2. pay for all Styles</p>
  
  <p>Number two is a newly added requirement. Before, it was primarily the PricingSchedule's Duration that determined the Price.</p>
  
  <p>My problem is this... the Price of a PricingSchedule doesn't mean anything when either the Duration, or StylePricingType is applied by itself. I can only get the final Price when they're combined together; aka, 2 years duration with 5 styles.</p>
  
  <p>We have four possible pre-determined durations, ranging from a couple of days, to a 3 or 4 years.</p>
  
  <p>We have two possible ways to bill Style selection; 1. per Style or 2. all Styles. These two things combined then determined the overall Price.</p>
  
  <p>I started thinking the Strategy design pattern could help me here, aka;</p>
  
  <pre><code>public interface IDurationPricingStrategy
  public decimal GetDurationPriceFor(PricingSchedule)
  
  public interface IStylePricingStrategy
  public decimal GetStylePriceFor(PricingSchedule)
  </code></pre>
  
  <p>This is a good way to separate things that probably will change going forward, but herein lies the rub; I can't implement one Strategy without knowing the other Strategy's "conditionals."</p>
  
  <p>For example, for the IStylePricingStrategy, I implement the unlimited style pricing option like so:</p>
  
  <pre><code>public class UnlimitedStylePricingStrategy : IStylePricingStrategy
  {
  public decimal GetStylePriceFor(PricingSchedule)
  {
  if (PricingSchedule.Duration.Type == DurationType.OneYear)
  {
  return decimal x;
  }
  if (PricingSchedule.Duration.Type == DurationType.TwoYears)
  {
  return decimal x;
  }
  }
  }
  </code></pre>
  
  <p>if I take this approach, that means if and when I have to add or change a Duration pricing type, then I have to change my StyleStrategy implementation class, which breaks SRP, and basically puts me back to square one.</p>
  
  <p>It's easy if there is only one "thing" that determines the Price for the PricingSchedule, but when I have two things like this, that's where I'm hitting a wall.</p>
  
  <p>Is there another pattern I can use, or somehow use the Strategy pattern differently? I feel that the problem still pulls me towards Strategy, but I'm not sure how to incorporate two Strategies instead of one.</p>
  
  <p>Thanks so much!
  Mike</p>