Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
2  
The more fine grained you specify your types the more compile time verification you can get that you aren't misusing any types. That said, I wouldn't create a type in your particular case and really don't know what you're talking about at all through the course of this question. –  Jimmy Hoffa Jun 24 '13 at 17:37
2  
@JimmyHoffa: "the more compile time verification you can get that you aren't misusing any types." Your solution is of technical nature and has got nothing to do with DDD –  EdvRusj Jun 24 '13 at 18:13
3  
That might be because I don't know anything about DDD, my comment is just that; a comment from my knowledge and experience and the fact that you talk about creating a class for Age which would generally be bad design. What quality it has in relation to DDD isn't something I can speak to, I can only speak to it's qualities in regards to writing and maintaining software. I didn't write an answer because I have no idea what you're talking about in here. My comment was technical in nature because this is a site for Programmers. Hi, I'm a Programmer. –  Jimmy Hoffa Jun 24 '13 at 19:15

1 Answer 1

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.

share|improve this answer
    
"It might be useful to have further subtypes such as DriverAge for drivers, which has logic particular to drivers" In that case we must create a subtype, since basic type doesn't contain a behavior required by age_of_driver attribute. –  EdvRusj Jun 24 '13 at 20:05
1  
Would it be correct to assume that in most cases self-contained attributes should have custom types only when different things/objects all contain the same kind of attribute A ( for example, all objects contain an attribute representing the concept of age ), but in each of these things A is named differently ( House.HouseAge, Person.PersonAge etc )? In that case it may be beneficial to create a custom type for A, so regardless if team is talking about an age of a house or a person, the use of the term "ThingAge" will make it obvious they are referring to the same concept of age? –  EdvRusj Jun 24 '13 at 20:07
1  
@EdvRusj: RE your first point: ThingAge could have some basic logic, such as the numeric age value must be greater or equal to $MIN_AGE and less than or equal to $MAX_AGE (assuming the system defines such a value). –  FrustratedWithFormsDesigner Jun 24 '13 at 20:58
1  
I generally think that custom types should only be created when they will actually have different functionality, or will be used in different ways (or there are clear future plans for them to be different/be used differently). Back to the insurance example: The system might want to distinguish different vehicle types: Motorhomes and Cars, but the age-related logic for them is the same, so they would both have an age attribute of the same type, VehicleAge. –  FrustratedWithFormsDesigner Jun 25 '13 at 13:30
1  
@EdvRusj: Ok, that's a little more clear. For me, I'd say that if the system can be refactored so references to ThingAge could be replaced with int and everything else would work fine, then int probably should have been used in the first place. I'm generally not a fan of adding new types to a system , when they are just containers for another type with no extra logic. –  FrustratedWithFormsDesigner Jun 25 '13 at 14:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.