This article describes the principles of reflecting the purposes and functions of business logic entities in metadata objects and their attributes. All of the listed recommendations are mandatory unless noted otherwise.
1. When designing application structure, use different object types for representing different entities. For example, use the Companies catalog for companies and the Departments catalog for departments.
2. To pinpoint object purpose you can add attributes to the object, so that its meaning and behavior change depending on the attribute values. For example, the Companies catalog can store both regular companies and subsidiaries, and the Employees catalog can store both current and former employees.
We recommend that in such cases you create dedicated attributes that uniquely identify the object kind or state. They can be Boolean attributes or enumerations that store object kinds. Do not determine object kind by indirect characteristics—in particular, by checking whether any of its attributes is filled.
- The Companies catalog has a ParentCompany attribute, and the attribute value defines whether it is a regular company or a subsidiary.
- In addition to the ParentCompany attribute, the Companies catalog has a Boolean attribute Subsidiary. The value of this attribute (True or False) explicitly defines the company type and whether filling the ParentCompany attribute is needed.
3. At the same time, if the Employees catalog has attributes HireDate and FireDate, adding a pair of Boolean attributes Hired and Fired is not reasonable. It is a good practice to create a single enumeration attribute for entities that can have multiple states. For example, an attribute can have states "works" and "fired", and you can add more states when needed.
Next page: Self-sufficiency of registers