Packages, Imports, and Scope

Packages are the fundamental organisational unit in Farkitect. Understanding how they work — and how imports connect them — is key to building well-structured models.

Why Packages?

A real-world model can contain hundreds or thousands of elements. Without structure, the Explorer becomes an unusable flat list. Packages provide:

• Hierarchy — nest packages inside packages to create a logical tree
• Ownership — every element, relationship, diagram, and catalog belongs to exactly one package
• Scope boundaries — M2 types are only available where they’ve been imported
• Portability — a package tree can be exported as a self-contained .farki file

Package Layers

Every package has a layer designation:

Layer	Purpose	Editable?
M3	System foundation (MOF Core)	No — always read-only
M2	Metamodels (modelling languages)	Built-in M2s are read-only; custom M2s are editable
M1	Models (your work)	Yes

The layer determines what a package can contain and how Farkitect treats it. M2 packages define types; M1 packages instantiate them.

Package Roles (M2 Only)

M2 metamodel packages use roles to tell Farkitect how to interpret their contents. The standard M2 package structure is:

My Metamodel (M2, standard)
├── Element Types (role: elementTypes)
│   ├── Business Layer (role: elementTypeLayer)
│   └── Technology Layer (role: elementTypeLayer)
├── Relationship Types (role: relationshipTypes)
├── Enumerations (role: enumerations)
└── Views (role: views)

• elementTypes — contains element type definitions, grouped into layers
• elementTypeLayer — a grouping within elementTypes (e.g., “Application Layer” in ArchiMate)
• relationshipTypes — contains relationship type definitions
• enumerations — contains enumeration types
• views — containers for diagram, catalog, and matrix view definitions

These roles are set when you create a metamodel using New Metamodel… — the structure is generated automatically.

Imports

Imports declare dependencies between packages. The most common pattern is an M1 package importing an M2 metamodel:

M1 Farquind Applications
  imports: [M2 ArchiMate 3.2]

When an M1 package imports an M2, the M2’s element types and relationship types become available in the Palette for any diagram in that M1 package. Without the import, the Palette would be empty (except for M2 Common types, which are always available).

Multiple imports

A package can import multiple metamodels:

M1 Farquind Organisation
  imports: [M2 ArchiMate 3.2, M2 Farquind Org Map]

The Palette then shows types from both metamodels, and you can create elements of either type in the same diagrams.

Import inheritance

Sub-packages inherit their parent’s imports by default. If M1 Farquind Applications imports ArchiMate, then a sub-package Customer Systems inside it also has access to ArchiMate types — without needing its own import declaration.

You can override imports on a sub-package if needed (for example, to add an additional metamodel import for that sub-package only).

Read-Only Packages

Packages can be marked read-only (isReadOnly: true). This prevents any modification to the package or its contents. Built-in M2 metamodels and M3 MOF Core are always read-only.

If you select an element in a read-only package and try to edit it, the Properties panel shows the values but the fields are not editable. This is by design — M2 definitions should not be casually modified, because changes affect all M1 instances.

Custom M2 metamodels you create are editable by default. You can mark them read-only when you’ve finished designing them and want to prevent accidental changes.

Projects and Packages

The relationship between projects and packages:

• A project is a container that holds packages and provides data isolation
• All packages in a project share the same M3 MOF Core
• M2 metamodels can be project-specific (custom M2s) or shared (built-in M2s)
• M1 packages are always project-specific — your model data lives in one project

When you export a package, the export is self-contained. When you import it into a different project, all the elements, relationships, and diagrams come along. If the import requires an M2 metamodel that isn’t in the target project, you’ll need to import that M2 first.