Domain Model and Data Modeling
This domain tests entity design: persistency, attribute types and validation rules, associations and their delete behavior, generalization, and reuse of System module entities.
Entities and attributes
- Persistent entities are stored in the database; non-persistent entities exist only in memory and are ideal as page helper objects or REST payload holders.
- Attribute types include String, Integer, Long, Decimal, Boolean, DateTime, Enumeration, AutoNumber (a system-assigned Long), Binary and HashedString. System.FileDocument is a persistent entity holding file content in a Binary attribute.
- Validation rules on attributes: required, unique, range, each with a custom message. Uniqueness is checked against the database at commit time, not when the user types.
Associations
- Reference covers one-to-one and one-to-many; reference set covers many-to-many.
- Exactly one side owns the association and stores the reference. Only the owner side can be changed in microflows.
- Delete behavior is configured on the association: cascade, prevent, or no action. Reference sets do not support cascading delete, so many-to-many clean-up must be modeled explicitly.
Generalization
A sub-entity inherits attributes and associations from its super-entity and adds its own. A 1-to-1 specialization can be used where the child must be exactly the parent object. Multiple inheritance is not possible.
Worked example
Requirement: deleting a Customer must never silently remove invoices, but should clean up the customer's addresses. Reasoning: Customer–Invoice gets prevent, so the delete raises an error you can catch and turn into a friendly message; Customer–Address gets cascade, because addresses have no meaning without the customer. Cascading both would silently destroy financial records - the exact design error exam items are built around.
Traps
- AutoNumber cannot be filled manually.
- A non-persistent entity can never be retrieved from the database.
- Delete behavior lives on the association, not on the entity.
- Validation rules do not fire on every keystroke; they fire when the object is committed.