Skip to main content

Designing a metamodel

Moving beyond the elements ontology​

Our metamodelling tooling provides the capability to design and configure the M2 level, i.e. a meta-model. This way, instead of forcing every single use case into our pre-existing structure (i.e. the elements ontology), you can define an entirely new standard tailored to the specific needs of the use case or domain.

1. Extend vs. Create from Scratch​

There are two major use cases that our metamodel tooling enables. Before designing, you must determine how your new domain logic relates to the existing ecosystem. There are two primary paths:

  1. Extend an existing metamodel: You want to add functionality, concepts, or structural rules to an already existing metamodel (like elements). This can mean two things. The metamodel you design extends an existing one (e.g extending elements with a structure for complex data queries). Another form of extending is when you don't necesssarily add features inside an existing metamodel, but rather build your own independent metamodel that "clicks" into an existing one (e.g., separating frontend and backend models).
  2. Create a Standalone Metamodel: You need an entirely independent M2 schema with its own architectural root (referred to in our tooling as a Program). This is ideal when your applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. looks completely different from a standard Management Information SystemSystemA set of interconnected components that work together to achieve a specific purpose or function. (MIS).

2. Why and When to Create a Metamodel​

Though NST information systemsSystemA set of interconnected components that work together to achieve a specific purpose or function., based on models that consist of NST elements, exhibit systemsSystemA set of interconnected components that work together to achieve a specific purpose or function. theoretic stability with respect to basic changes, many software designers might – and do – prefer other kinds of models for software systemsSystemA set of interconnected components that work together to achieve a specific purpose or function., or consider the NST elements model to be lacking in capabilities they need. Because introducing an unjustified metamodel compromises conceptual integrity, evaluate your requirement against two key criteria before proceeding:

  • Incompatibility vs. Inconvenience: Can your requirement be reasonably or elegantly expressed using standard NS elements? If a feature can be solved by adding a new expander bundleExpander BundleA set of expanders sharing a repository, packaged into an expansion resource or archive. to the existing metamodel, do that instead. A new metamodel should only be introduced when there is a true structural incompatibility, not just a temporary inconvenience.
  • Domain Alignment: Are you still building a Management Information SystemSystemA set of interconnected components that work together to achieve a specific purpose or function. (MIS), or do you need to describe a domain that operates on completely different structural rules? If your applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. requires an entirely new language, unique architectural constraints, and rules that fundamentally clash with standard elements, then creating a new metamodel is indeed the correct solution.

3. Which Pattern Fits Best?​

After verifying that your use case truly requires a new metamodel, let's revisit the architectural patterns described in the first step. To help you map your requirement to the right choice, here is how those patterns look in practice:

Pattern 1: Addendum-like metamodel extensions​

Injects brand-new functionality and concepts directly into an existing metamodel.

  • Messaging Metamodel: Extension built on top of elements to introduce pub/sub messaging. It allows you to model event-driven communication straight from within an elements::Component.
  • Document generator metamodel: A separate addendum metamodel designed to handle and automate document generation rules for standard NS Data ElementsData Element (DataElement). A fundamental data concept or entity within an application's domain, acting as an anthropomorphic translation of a real-life object or concept..

Pattern 2: "Clicking" metamodels together (Interlocking Extension)​

Independent metamodels that maintain a clean structural reference to hook into another metamodel at specific touchpoints.

  • Frontend Metamodel: Describes UI model for NS MIS. It defines its own root, making it technically standalone, but features a reference to hook directly into the backend elements metamodel, seamlessly binding the frontend and backend.
  • Domain Driven Design (DDD) metamodel: A specialized framework enabling architects to model software using DDD principles. It maintains a reference to elements, allowing it to benefit directly from our extensively expanded logic layersLayerLogical separation of functionality within a single system/application, focused on code organization..

Pattern 3: Standalone Metamodels​

An entirely new specification that completely breaks away from standard NS elements to build a brand-new architectural root.

  • DoleEdge Metamodel (Industrial IoT): Built around native concepts like Sensors and Actuators to deploy code directly to edge devices, completely ignoring e.g. standard relational databases and user forms. ** Code Insight metamodel: A project providing support for the analysis of expanded code. The meta-model and expandersExpanderA unit of generation that combines a data tree instance (functional M1 model) with a template to generate an artifact. create a model of generated artifactsArtifactA build or deployment result, such as a Docker container image or Java archive, produced by a software project.. Since it is its own applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. analyzing an NS codebase, it requires a standalone metamodel.
  • Physical Infrastructure Metamodels: Used for mapping out fiber-optic networks or electricity grids where the domain inherently requires a topology based on connectivity, routing laws, and physical capacities. A standalone M2 built entirely around industry-specific concepts allows you to model these environments accurately.

Developer Hub​

There are various developer guides to help you get started with metamodelling