Model

The model describes architecture as a set of hierarchical elements and any relationships among them.

Element

Element is a basic building block.
It represents a logical or physical part of the architecture.
Any element must have a kind and a name (identifier):

specification {
  element actor // define a kind
  element service
}

model {
  // element of kind 'actor' with the name 'customer'
  actor customer
  // element of kind 'service' named as 'cloud'
  service cloud

  // also possible with '=' and the name goes first
  cloud = service
}

Element name is required for references.
It can contain letters, digits and underscore, but can’t start with a digit.

name
api	✅
Api	✅
_api	✅
_1api	✅
1api	⛔️
a.pi	⛔️

Element Properties

Elements may have properties: title, description and technology.
For example, Structurizr DSL style:

specification {
  element softwareSystem
}
model {
  // Structurizr DSL style:
  // <name> = softwareSystem [title] [description] [technology]
  cloud = softwareSystem 'Cloud' 'Provides services to customers' 'SaaS'
}

Note

LikeC4 supports Structurizr DSL syntax (“partially”) allowing to copy-paste from it.
Check the Big Bank example.

Element’s name is used as a title by default.
But you can specify your own:

model {
  // element of kind 'actor'  with name='customer' and title='customer'
  actor customer
  // element of kind 'service' with name='cloud' and title='Cloud Systems'
  service cloud 'Cloud Systems'

  // or with '='
  cloud = service 'Cloud Systems'
}

These properties may be defined as nested:

model {
  // Only description inside
  customer = actor 'Customer' {
    description: 'Uses the Mobile Application' // ':' is optional, but if you prefer
  }
  // All properties inside
  mobile = application {
    title 'Mobile Application'
    description 'Provides services to customers'
    technology 'React Native'
  }
  // Multiline
  web = application {
    title 'Web Application'
    description '
      Provides services to customers through
      the web interface.
    '
  }
}

Element Tags

Tags are defined in nested block and before any properties:

model {
  appV1 = application 'App v1' {
    #deprecated
    description 'Old version of the application'
  }

  // multiple tags
  appV2 = application {
    #next, #serverless
    #team2
    title 'App v2'
  }

  appV3 = application {
    title 'App v3'
    #team3 // ⛔️ Error: tags must be defined first
  }
}

Element Links

Element may have multiple links:

model {
  bastion = application 'Bastion' {
    // External link
    link https://any-external-link.com

    // or any URI
    link ssh://bastion.internal

    // or relative link to navigate to sources
    link ../src/index.ts#L1-L10
  }
}

Structure

Any element is a container and can contain other elements.
This way you define the structure and internals of the element.

model {
  // service1 has backend and frontend
  service service1 {
    component backend {
      // backend has api
      component api
    }
    component frontend
  }

  // or use '='
  service2 = service {
    backend = component {
      api = component
    }
    frontend = component
  }
}

Caution

Element name must be unique within the container.
We learn this in detail with references

Nested elements are “namespaced”, the parent name is used as a prefix.
So, the model above has the elements with these fully qualified names:

• service1
• service1.backend
• service1.backend.api
• service1.frontend

and:

• service2
• service2.backend
• service2.backend.api
• service2.frontend

It is not possible to have elements with the same name on the same hierarchy level.

model {

  service service1 'Service 1' {
    component backend

    component backend // ⛔️ Error: 'service1.backend' already defined
  }

  service service2 'Service 2' {
    component backend // ✅ This is OK - 'service2.backend'

    component legacy {
      component backend // ✅ This is OK - 'service2.legacy.backend'
    }
  }

  component backend // ✅ This is OK - 'backend'
}