Every system has the concept of ‘hierarchies’. It’s a term that appears in every conversation about domain models. But it’s important to understand what kind of hierarchy is being discussed – because the term has different meanings.

1) Hierarchy meaning “Structure“

Hierarchical structures focus on the assembling of information. Aspects such as Aggregate Design, parent/child relationships, and relationships to other entities fall under this category.

Here is an example of a car, using UML. The filled in diamonds represent a composition (aka “owns”) relationship:

Within Fresnel, Explorer Cards help to visualise and navigate this structure. The main Aggregate appears as a card, and related objects appear as nested blocks that may be expanded:

Any nested object may also be explored in its own card:

2) Hierarchy meaning “Taxonomy“

Taxonomies focus on ‘similarities’ of entities.  In OO design, this is synonymous with types and inheritance. This is the trickier aspect of design, and often needs more than just a casual understanding of the domain. You may need multiple design iterations to get the hierarchy right.

In this example, there are two types of Parts (the arrow points to the general type):

• An Assembly is a kind of Part
• A Component is also a kind of Part
• An Assembly is a part that is composed of other parts
• A Component is a single part, with no other parts within it

Because a Section has a collection of Parts, Fresnel only allows objects of the correct type to be added to the set:

When designing type hierarchies, use the Liskov Substitution Principle to see if the subclasses work correctly within the context of the containing object. Fresnel makes it very clear if a type hierarchy works, because the drop-down reflects only the possible options.

Continuously exploring these hierarchies will refine your model (and, more likely, expose new concepts in the domain).

What about using Enums or Value Objects or Enums to simplify the design?

If multiple entities can be described using exactly the same properties, use an Enum (or Value Object) to differentiate them. You may need to add custom conditional logic in your code, if you have to make choices based on the type.

Experiment with two models: one that uses type inheritance, and another that uses enums. Test those models with your Domain Experts, to see which works best within the problem space.