Your base taxonomy defines the core set of types that are used to describe services and models. They're the building blocks that form the basis of your organisation's taxonomy.
Think of your taxonomy as a shared vocabulary, rather than as a series of shared models. (See the Common Domain Model Antipattern for more detail)
A good sign of a well defined taxonomy is one that can be applied easily by service developers throughout their own domain models.
Models are great, but they're best left to individual systems to define, rather than the central taxonomy.
Try to keep your central taxonomy populated with terms, are than models. Therefore, be careful as you start to add attributes to items in your central taxonomy, as it starts to become a shared domain model, which has real drawbacks.
Whenever you add an attribute, remember that all consumers and publishers have to be able to satisfy the contract, or they won't be able to use the type. You're often better off defining the attributes independently. This allows consumers of the taxonomy to compose and arrange the attributes in ways that are meaningful to them.
This isn't to say that nested, tree structure models aren't useful - they are. But we think that the developers of services should define the models that are most meaningful to them. This is easier to do when the taxonomy contains simple types.
Do: Select the most appropriate type to model the concept. Encourage others to do the same. Avoid: Typing things as 'String', when another type is a better fit.
When building a rich semantic model for describing business terms, inheritence is a powerful way to increase the richness of terms.
In Object Oritented software, inheritance is often discouraged.
However, in taxonomy land, when were modelling single-attribute types, inherits
is a great way building a heirarchy of specialisation.
type Name inherits Stringtype FirstName inherits Nametype LastName inherits Name
Inheriance works in a single direction. ie., using the above example, we can say:
All
FirstNames
are alsoNames
, but not allNames
areFirstNames
Type aliases are useful for indicating two ideas (generally from different taxonomies or schemas) mean exactly the same thing.
type FirstName inherits Nametype LastName inherits Nametype alias GivenName as FirstName // GivenNames and FirstNames are interchangeabletype alias Surname as LastName
Only use type aliases when two things are entirely interchangable. If things are similar, but synonymous then avoid type aliases, and consider inheritance instead
Use inheritence when you want to capture that something is a specialisation of a concept, rather than for modelling the context surrounding a concept.
ie., avoid specialising types to cater for concepts such as:
Who created it
When it was created
Where it was published
For example, avoid things like:
// Don't do thistype AmazonPrice inherits Price
An upcoming language feature called Context is intended for modelling this type of information