Software Engineering is Contracts
Everything is a Contract.
- Methods are contracts.
- APIs are contracts
- Conceptual State encapsulations are contracts ( i.e. multi value state so non "scalar", non single value state ).
- Service APIs are contracts.
- Framework and Library public interfaces are contracts.
- Internal IOC Service public interfaces are contracts.
- Even the internal private interfaces are contracts to something.
- SDK Interfaces
- Database Tables
- PROTOCOLS for how you actually interact with an API or database are contracts.
And contracts without schema are bad. All of them. If your contract doesn't have a schema. It's bad.
Rules of Contracts
No "conditionally optional" or "conditionally relevant" or "one of these fields is required" type multi-field relationships. Please use polymorphic encapsulation to declare what fields are required and what aren't, so that if something is done wrong, the developer using your library or API, knows at compile time.
What is polymorphic encapsulation?
Instead of This
{
A: Product Name
B: Product type
C Product Attribute X ( Required if B is one )
D Product Attribute Y ( Required if B is two )
} // let's do this with json schema yeah?
Do This
{
A Product Name
B /*ProductTypeSpecificConfig*/ one of [{
Product Type: one
Product Attribute X
},
{
Product Type: tow
Product Attribute Y
}, ]
}
This way when I deserialize, it's impossible for me to dereference a field that may not be relevant to the type of product I'm working with.
TODO: Improve this post. I should make it a draft, but I want to publish it raw...
Prefer Peer associations with XREF tables over Parent/Child Associations with directly embedded foreign keys.
The latter is coupling and overstates contract on the observing entity.
Associations as first class citizens.
Comments
Post a Comment