Views

Views are the architecture diagrams, projections of the model from different perspectives, with different levels of details, like:

System / service overviews
Components interactions in specific use case
Data flows and sequence diagrams

View definition

Views are defined in views section.
Views may be named (must be unique) or unnamed (can't be referenced):

views {
  // with name
  view index {
  }
  // unnamed
  view {
  }
}

View's name is used as a filename during the export, and a URL part for the sharing, so better to define it.

index is a special view, and is rendered by default if no view name is specified.
If not defined, it will be generated for top-level elements

Views may have a title, description, tags and links (same as model element):

views {
 
  view epic12 {
    #next, #epic-12
    title "Cloud System - Changes in Epic-12"
    description "
      This diagram shows the high-level
      components and interactions.
    "
 
    link https://my.jira/epic/12
 
    include *
  }
 
}

View Of ...

View may be defined for some element (view of ..).
View inherits the scope of the element:

views {
 
  view {
    include api // ⛔️ Error: 'api' is not found
  }
 
  view of cloud.backend {
    include api // ✅ This is OK, references 'cloud.backend.api'
  }
 
}

This view becomes the default view for the element:

views {
 
  view view1 of cloud.backend {
    include *
  }
 
  view {
    // on click navigates to 'view1', because it is the default view for 'cloud.backend'
    include cloud.backend 
  }
 
}

You may have multiple views for the same element, but which one is selected as default is not determined.

Custom navigation

It is possible to define custom navigation and links between views:

 
view view2 {
  include *
  include cloud.backend with {
    // navigate to 'view3' on click
    navigateTo view3
  }
}
 
view view3 {
  include *
  include cloud.backend with {
    // the same element, but navigate back to 'view2'
    navigateTo view2
  }
}

Custom properties

It is possible to customize the properties of the element for the view:

view {
  // Include the element and override its properties
  include cloud.backend with {
    title 'Backend components'
    description '...'
    technology 'Java, Spring'
    color amber
    shape browser
  }
}

View predicates

View predicates define what elements/relationships to include/exclude.

// include element
include cloud.backend
 
// or exclude
exclude cloud.backend
 
// include children of cloud.backend and all the relationships
// among them and the elements of the view
include cloud.backend.*
 
// all incoming relationships
// if any found - includes cloud.backend and source elements
include -> cloud.backend
include * -> cloud.backend
 
// all outgoing relationships
// if any found - includes cloud children and target elements
include cloud.* ->
 
// all relationships from customer to cloud children
// if any found - includes customer and targeted children
include customer -> cloud.*
 
// elements by kind
include element.kind = container
include element.kind != system
 
// elements by tag
include element.tag = #next
include element.tag != #V2

Limitation
Relations with container elements are not rendered yet. Working on it...

⚠️

TODO:
Document why relationships predicates are awesome

Wildcard may be used to reference "everything", but it depends on the context.

view {
  // include all top level elements and their relationships
  include *
}
 
view of cloud.backend {
  // include 'cloud.backend', its children and all the incomings/outgoings
  // (relationships with the rest of the architecture)
  include *
}

Predicates are applied in same the order as defined in view.
exclude applies only to elements/relationships included before.

view of bigbank {
  // rules may be merged
  include
    customer,
    bigbank,
    customer -> bigbank.*
 
  // exclude all children of bigbank
  exclude bigbank.*
 
  // but include webApplication
  include bigbank.webApplication
}

Style rules

Style predicates define how elements are rendered.
Example from BigBank:

view apiApp of internetBankingSystem.apiApplication {
 
  include *
 
  // apply to all elements
  style * {
    color muted
  }
 
  // apply only to these elements
  style singlePageApplication, mobileApp {
    color secondary
  }
 
  // apply only to apiApplication and its descendants
  style apiApplication, apiApplication.* {
    color primary
  }
 
  // apply only to the tagged elements
  style element.tag = #deprecated {
    color muted
  }
}

Custom properties have higher priority than style rules.

Extend views

Views can be extended to avoid duplication, create a "baseline" or, for example, "slides" for a presentation:

views {
 
  view view1 {
    include *
  }
  
  view view2 extends view1 {  
    title 'Same as View1, but with more details'
 
    style * {
      color muted
    }
 
    include some.backend
  }
  
  // cascade inheritance
  view view3 extends view2 {
    title 'Same as View2, but with more details'
    
    include * -> some.backend
  }
 
}

The predicates and style rules of extended views are merged with the ones from ancestors.

Extended views also inherit the scope:

views {
 
  view view1 of cloud.backend {
    title 'Backend components'
  }
 
  view view2 extends view1 {  
    include api // ✅ This is OK, references 'cloud.backend.api'  
  }
 
}

Styling Workspace