In my previous blog, I gave a few reasons to consider building validation by design. Before diving into available technology and tools, next articles will cover top 7 things to know about validation, regardless of how validation is implemented.
Scope
The starting point of validation is a business rule defined over one or more business objects. From technical point of view a business object is realized as one or more Mendix entities (a.k.a. information objects) that are also enriched with attributes. Therefore, when developing a validation rule, one of the most apparent technical properties is that the rule may require single or multiple values as input. The first case is the most simple as input value typically comes from an attribute of a single entity. In the second case, the values may belong to attributes of the same or different objects (records in database terms). It is important to emphasize that objects may be instances of the same or different entities.
It follows that a validation is intra-object if it uses one or more attributes that belong to the same object.

In the above example, a validation rule checks if value of attribute Remark is sufficient given the value of another attribute Reason. The validation only fails if Remark is empty and the selected reason is “Other”. Both attributes Remark and Reason belong to the same object of entity Cancellation.

In contrast, inter-object validation requires access to attributes of multiple objects. Objects can be of the same entity or of different entities. Validation may need to access attributes of objects, or simply establish if one or more object exist.
The above figure shows a validation rule that checks the status value of the current reminder object, given the status of the previous object. Validation succeeds if the last status was “Initial” and current one is “_Final”. In all other cases the validation fails. The two inputs of the rule are provided by attributes from two different objects of the same entity Reminder.
Composability
Within an application, validation can be used in different places, typically when interacting with users or systems and managing objects. Depending on usage, not all, but selected validation rules may be needed. Naturally it would be the best to select and re-use available rules with minimum effort.
A highly composable validation system allows any of its components to be selected and re-assembled in various combinations to satisfy specific needs.
A single validation that is not composed of any other validation is known as atomic. On the other hand, a validation that is composed of two or more validations (not per se atomic ones) is sometimes called compound validation.

The above figure illustrates a compound validation, consisting out of two atomic rules, each performing a simple validation on an attachment object. If needed, the assembly of the contained validations can be easily modified.
Technical/Business
It is useful to distinguish validations that are common across all business data. These are related to basic data types, such as strings, integers, currency, etc… and are known as technical validations. They are found basically in all data persistence services (i.e. databases). By its generic nature, a technical validation usually is atomic and has a scope of a single attribute within an object.
While extremely useful, technical validation is not sufficient to cover all needs for correct business data. The rest, also known as business validation, is shaped by needs of a specific business.
A simple example is age of an adult allowed to drive. While basic type for age is integer, the minimum age in the Netherlands is 17 years and depending on application domain, maximum age might be desirable too.
Note that term business does not per ce refers to vertical domains such as banking, finance or insurance. A business can also belong to a horizontal domain, such as Java. An example of application for Java domain is a software factory.
To Be Continued…
In the next article I will continue exploring the domain of validation. Meanwhile, if you have any questions or suggestions feel free to contact me at my email address andriy.levytskyy@pinkelephant.nl.
Gerelateerde artikelen
- Lees meerBlogEventsNieuws
PinkSail2020
We hadden het zo mooi bedacht: een deal met de organisatie van Sail2020 waarbij Pink, in ruil voor een schip…
- Lees meerBlogBusiness SimulationOpleidingen
City construct: a scrum simulation game
Pink Elephant heeft onlangs een eigen Business Simulion Game op de markt gebracht: City Construct. In deze game leren deelnemers…
- Lees meerBlogOpleidingen
Webinar Service Automation
Bekijk het webinar van Pink Elephant trainer Richard de Boer over Service Automation: het automatiseren van klantdiensten, waarmee de gebruikerstevredenheid…
- Lees meerBlogCloud ComputingNieuws
Citrix Summit ’19
Begin januari zijn Pinkers Raymond Sijsenaar en Jur Huisman aanwezig geweest bij de Citrix Summit in Orlando. Deze driedaagse beurs…
- Lees meerArtikelenBlogBusiness SimulationNieuws
Best Practice Prediction 2019
Het einde van het jaar nadert en dit roept de vraag op wat ons te wachten staat in 2019 wat…
- Lees meerBlogITSMOpleidingenTrainingen
Het nieuwe ITIL® 4 certificeringspad
AXELOS heeft onlangs het nieuwe certificeringspad voor ITIL® 4 gelanceerd: Het huidige ITIL® v3 certificeringspad is zeer uitgebreid. Het…
- Lees meerBlogE-learningNieuwsOpleidingen
En m’n ITIL® V3 certificaat dan….?
ITIL® V3 wordt ITIL® 4 Begin september brachten we jullie groot nieuws: er komt een nieuwe versie van ITIL®, namelijk…
- Lees meerBlogOpleidingenTrainerTrainingen
DevOps: “The Wall of Confusion”
DevOps helpt met het verminderen van Silo-denken tussen Development en Beheer.