Types
Cornerstones for domain representation
Domain Types or Business Archetypes are often confused with data types. This leads to less expressivity and incomplete representation of the domain model. It denies a modeller or architect the opportunity to have a single source of truth for the domain model, potentially leading to fragmentation, inconsistency and dissonance in System Design. This further curtails maintainability and extensibility in terms of design and implementation!
The notion of pure types is often misunderstood and overlooked by software designers and developers alike.
Would you compare a person's name and an organisation's name?
Would you compare the data of birth and date of joining?
Would you compare the salary and age?
Ideally, the above comparisons should imply a "type mismatch" from a business domain perspective, whereas technically, in most realisations today, comparisons are possible because the underlying data types for these remain the same.
The data type for a person's name and organisation's name is String
The data type for the date of birth and date of joining is Date/DateTime
The data type for the salary and age is a Number (Double and Integer, respectively)
But one can argue such business semantics can be easily enforced. Yes, it can be, but at multiple places (layers in the system) in multiple ways (often at the mercy of the implementor)! This potentially leads to fragmentation of truth and inconsistency in system behaviour.
Domain Model representation is the key here. If all the truths of the domain (including entities, states, workflows, user roles, user actions, and business rules) could be represented coherently and all programs derive their purpose from these representations, one could argue this would be an ideal state of virtualization of the problem domain.
There's a striking correlation between the above statement with logic and mathematics. Imagine every truth or fact, or proposition about the domain can be represented in some form. Types (entities, for starters) go a long way in representing this. Then the program that codifies this or works with these types would be the proof equivalent of the problem domain. And finally, the program evaluation (in the context of any use case) is about the proof's normalisation (or simplification). Well, this is Curry-Howard Isomorphism/Correspondence!
A few notable References:
Last updated