Applying “make invalid states unrepresentable”
In general I agree that it&#x27;s nice to make invalid states unrepresentable, but I&#x27;m not sure if I agree that this counts as a fundamental &quot;invalid state&quot;. There is nothing about contracts which require that you can only have one active at the same time, or that that current one must be open ended.<p>From a practical point of view it might be advantageous if you maintain only a single contract with a customer at all times, but that is a <i>business</i> requirement which might be changed in the future.<p>I mention this mostly from experience: Multiple times I&#x27;ve designed systems where I&#x27;ve reduced the representable states to the minimum, and when some requirements change I realize I have to re-design the full system.<p>The new presented representation might make sense in <i>this</i> situation, but I&#x27;d be very wary of taking current business practices and make all other alternatives <i>impossible</i> to represent. It&#x27;s a balancing act of course as you can go in the opposite direction and make it way too flexible.<p>&gt; This poor choice was not just a theoretical problem - gaps in contracts were found on more than one occasion, requiring hours of engineering effort to hunt down and fix.<p>I&#x27;d like to hear more about what happened here. Was the problem that the default contract was not re-applied correctly? If so, changing the representation might not actually solve any problems — it make actually make it _worse_. A renewal of a contract typically involves some automated process where other services are involved (payment, invoicing, emails). The previous representation (with explicit start&#x2F;end dates) made it possible for you to verify that everything was correct and lined up.