Building your base taxonomy
How to come up with a robust taxonomy
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.
Types, not models
Avoid types with attributes
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.
Use the correct base type
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.
Inheritance & Aliases
When building a rich semantic model for describing business terms, inheritance is a powerful way to increase the richness of terms.
inherits to increase specificity
In Object-oriented software, inheritance is often discouraged.
However, in taxonomy land, when were modelling single-attribute types,
inherits is a great way building a hierarchy of specialisation.
type Name inherits String type FirstName inherits Name type LastName inherits Name
Inheritance works in a single direction. ie., using the above example, we can say:
Names, but not all
Use type aliases when things are synonymous
Type aliases are useful for indicating two ideas (generally from different taxonomies or schemas) mean exactly the same thing.
type FirstName inherits Name type LastName inherits Name type alias GivenName as FirstName // GivenNames and FirstNames are interchangeable type alias Surname as LastName
Avoid system-specific and publisher-specific variations in the base taxonomy
Use inheritance to refine the "what", not the "who", "when" or "where"
Use inheritance 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 this type AmazonPrice inherits Price