Skip to content
🤷

Forgive us! These docs are a work in progress. Some pages may be incomplete or describe features that aren't quite finished yet. Farkitect is in early development and we don't recommend using it for real work just yet. Feel free to explore — just be aware that things are still being built.

How Farkitect Uses MOF

The Meta Object Facility (MOF) is an OMG standard that defines a layered architecture for metamodelling. Farkitect uses MOF as its structural foundation — but makes specific implementation choices that are worth understanding if you want to know how things work under the hood.

MOF defines four layers (M0–M3), but in Farkitect you work with three:

M3 contains MOF Core — the definitions of what metamodels themselves can contain. It answers the question: “What kinds of things can exist in a metamodel?”

MOF Core defines concepts like Class (which becomes an element type), Property, DataType, Enumeration, and Relationship. Every M2 metamodel is built from these M3 building blocks.

In Farkitect, M3 is:

  • Always present in every project
  • Read-only — you never edit M3
  • Visible in the Explorer with red text, if you want to inspect it
  • Foundational — it’s the bedrock that makes everything else possible

You can expand M3 MOF Core in the Explorer to see what’s inside, but you’ll never need to change it. Think of it as the grammar rules of the English language — you use them constantly without ever needing to modify them.

M2 is where modelling languages are defined. Each M2 package is a metamodel that specifies:

  • Element types — the kinds of things users can create (e.g., Application Component, Business Process, Entity)
  • Relationship types — valid connections between element types (e.g., Serving, Flow, Generalization)
  • Properties — typed fields on element types (e.g., Lifecycle Status as an enumeration, Start Date as a date)
  • Enumerations — controlled value sets (e.g., Priority: High, Medium, Low)
  • Notation — visual appearance rules (shape, colour, icon, compartments)
  • Constraints — pair-wise rules controlling valid source/target combinations for relationships

Farkitect ships with built-in M2 metamodels (ArchiMate 3.2, UML, C4, etc.) and supports creating custom M2s. Built-in M2s are marked read-only; custom M2s are fully editable.

M1 is where your actual modelling work lives. M1 elements are instances of M2 types:

  • An M1 element classified as “Application Component” (from ArchiMate M2)
  • An M1 relationship classified as “Flow” (from ArchiMate M2)
  • Property values filled in according to the M2 property definitions

M1 is where you create packages, elements, relationships, diagrams, catalogs, and property values. This is the layer you interact with most.

The link between M1 and M2 is the classifier. Every M1 element has a classifierId that points to its M2 element type. This is how Farkitect knows:

  • What properties the element should have (defined by the M2 type)
  • What it should look like on diagrams (notation from the M2 type)
  • What relationship types are valid (constraints from the M2 type)
  • What compartments to render (subordinate types from the M2 type)

The classifier is assigned when you create an element — by dragging from the Palette or selecting a type in the element picker. Once set, the classifier determines the element’s behaviour throughout its lifecycle.

M1 packages declare which M2 metamodels they use via imports. When an M1 package imports an M2 metamodel, the metamodel’s element types and relationship types become available in the Palette for diagrams in that package.

A single M1 package can import multiple M2 metamodels — this is how you combine modelling languages in one project. For example, an M1 package might import both ArchiMate (for application modelling) and a custom Org Map metamodel (for people and teams).

For more on how packages and imports work, see Packages, Imports, and Scope.

The MOF layer architecture provides:

  1. Separation of concerns — the modelling language (M2) is separate from the model content (M1). You can change the language without touching the models, and vice versa.
  2. Type safety — every element has a classifier, which means Farkitect can validate, render, and constrain it correctly.
  3. Extensibility — new modelling languages are just new M2 packages. No code changes needed.
  4. Interoperability — MOF is an international standard. Models built in Farkitect have a well-defined structure that tools and people can understand.