Q: Why relationship patterns ?
A: To explore and improve how we describe and build complex systems by focusing on relationships—moving beyond basic composition to more expressive ways of relating entities.
Relationships are hard. We all struggle to understand how to interpret them to make our lives easier.
Trying to make sense of how the world's things and our many ideas about it relate with one another, and impact our understanding likely began with Aristotle, as he categorized entities in hierarchical and compositional ways.
In his work “Categories and Metaphysics”, Aristotle laid the foundations for understanding entities and their relationships. He introduced taxonomy (hierarchies of "isA") and distinguished between:
More explicit consideration of association and aggregation emerged with modern logic (19th century) and became formalized with database and programming models (20th century).
Here the focus is on relationships and how do describe and build complex systems by creating and relying on more expressive relations.
Different programming models think about relationships in different ways. For example, most programming languages use composition to define the system structure and behaviour, whether it's Object, Function or Module composition. Component based architectures, Relational and Document databases, HTML, frameworks like React, and many other technologies use composition. Composition is pervasive when thinking about building systems.
The list below shows the relation types we aim to support.
| Concept | Short Form | Description | Taxonomic |
|---|---|---|
| Inheritance | isA | Hierarchical specialization of entities. Sub-Entity type is a specialized Entity type. |
| Structural | ||
| Composition | has | Strong ownership; part lifecycle tied to the whole. Entity has, or is made of other entities, which belong to this entity and cannot be part of, and cannot be transfered to be a part of other entities. |
| Aggregation | contains | Weak ownership Entity contains entity part(s) which exists independently, and can change where it belongs over time. |
| Instantiation | isAnActual | Links entity types to actual instances. The Entity linked to is an actual entity, an instance of the entity type. |
| Behavioral | ||
| Association | associatesWith | Entity type associates with one or more independent entities, which can associate with other entities at any given time. Loose connection; no ownership or lifecycle implications. |
| Dependency | needs | Represents functional reliance or need. Entity needs one or more entity dependencies. |
| Behavioral | ||
| Alias | is | Defines equivalence or synonymity between entities. Entity alias is the same as the original entity, except its ID. |
| Complex | ||
| Conditional Relation | <any> | Relation only applies when condition is true. |
| Custom Relation | <custom> | Allows for extensibility. Programmers can add their own relationships. |
| Managed Relation | manages | Provides for an entity and its associatiations along the managed relation a way to auto-generate entities. |
| Taxonomic Composite | extends? | A taxonomy models hierarchical relationships, while a composite pattern manages "whole-part" relationships. |
| Filtering entities | filters | Filters an entity based on a criteria. |
| Composite Facts | Composes Facts from the basic Facts. | |
| Data Aggregation | groupBy | Aggregates measurement data across multiple dimenstions, based on the aggregation logic provided. |
| Code Extensibility | code | Fallback to code through extensibility points. |
| I/O relation | io | Integrating with system I/O based using Code Extensibility. |
| System relation | system | Integrating with the platform's systems using Code Extensibility. |
Provides for an entity and its associatiations along the managed relation a way to auto-generate type.
A taxonomy models hierarchical relationships, while a composite pattern manages "whole-part" relationships. This term highlights the structure's alignment with classification systems and composition.
This is a recursive Dual-Hierarchy Composite-Inheritance Pattern describing a Multi-Dimensional Ontological Model of 2 hierarchies:
Each level builds on the previous one, and the entities in both the inheritance and composition hierarchies follow a consistent progression.
The goal here is to simplify the management of this data, by inferring inheritance from the commposition data and keep the data in sync across the two relations between the two hierarchies.
Given a hierarchical type system describing Administrative Regions, a lot of types would need to be generated to support the creation of entities.
Below it shows the composition hierarchy. This hierarchy's data obviously can be derived from the inheritance hierarchy's data. When creating a new city of a certain type, it can be safely placed under that type's associated entity.
CA_ON_Hamilton = Canada_ON_City.new() => CA_ON_Hamilton.isA(Canada_ON_City) && Canada_ON.has(CA_ON_Hamilton).
The AdministrativeRegion entity below has 4 sub-types:
Each specifies its direct children in the composition relation.
It also specifies which entity it manages the composition for (managesCompositionFor).
Running the script below generates the extensive type system and the composition hierarchy.
Filters an entity based on a criteria.
Composes Facts from the basic Facts.
Aggregates measurement data across multiple dimenstions, based on the aggregation logic provided.
Fallback to code through extensibility points.
Integrating with system I/O based using Code Extensibility.
Integrating with the platform's systems using Code Extensibility..