> have a DefaultContract entity of some kind somewhere
This is the OO mindset described at the bottom - the odd compulsion to have a reified entity for every concept.
A lot of people have missed that the representation you persist doesn't have to match the representation you present. In this case, don't store default contracts, but present them e.g. via a database view.
But nothing of this has to do with OO. This is an argument at the relational level.
And yes, if there's something as fundamental a concept in the business model as a default contract that's in effect when no other contracts overrule it, then IMO it damn well should be represented explicitly in the persisted data model.
I didn't talk about the specific nature of the representation. The important part is that the intent of the data should be explicit - data lives longer than code.
I've seen far too many DB schemas leaning too hard on implicit assumptions and inferring information that lead to hard to understand data models, unnecessary complex (and hard to optimize) data access (no matter the paradigm), and well, lots of errors.
This is the OO mindset described at the bottom - the odd compulsion to have a reified entity for every concept.
A lot of people have missed that the representation you persist doesn't have to match the representation you present. In this case, don't store default contracts, but present them e.g. via a database view.