Note that my question is referring to those attributes that even on their own already represent a concept ( ie on their own provide a cohesive meaning ). Thus such attribute needs no additional functional support and as such is self-contained.
I’m also well-aware that even with self-contained attributes the custom types may prove beneficial ( for example, they give the ability to add new behavior later, when business requirements change ). Thus, my question focuses only on whether custom types for self-contained attributes really enrich Ubiquitous Language UL
a) I’ve read that in most cases, even simple, self-contained attributes should have custom, more descriptive types rather than basic value types ( double, string … ), because among other things, descriptive types add to the UL, while the use of basic types instead weakens the language.
I understand the importance of UL, but how does having a basic type for a self-contained attribute weaken the language, since with self-contained attributes the name of the attribute already adequately describes the concept and thus contributes to the UL vocabulary?
For example, the term person_age already adequately explains the concept of quantifying the number of years a person has:
class Person
{
string person_age;
}
so what could we possibly gain by also introducing the term ThingAge to the UL:
class person
{
ThingAge person_age;
}
thanks
3
If you have a system that considers ages of different “things”, then having a ThingAge type could be useful. For example, an insurance software system considers the age of drivers and the age of vehicles (for automobile), the age of buildings (for home and commercial property). It might be useful to have further subtypes such as DriverAge for drivers, which has logic particular to drivers (such as related to being above/below regional minimum driving ages), and other types such as HouseAge that has logic related to regional heritage structure rules. EquipmentAge might relate to mechanical/industrial equipment that might be relevant for underwriting.
Of course, in such a system you don’t need to have ThingAge, DriverAge, HouseAge, EquipmentAge types; it’s just one way to do it that may be legitimate in some systems. In others, it might not be a good way to do it.
If your system will only ever consider “people” as having an “age” attribute, then having a ThingAge type might not be very useful.
8