The workspace "" has been client-side encrypted, please enter the passphrase to decrypt it.
The workspace could not be decrypted.
Workspace editor
This is the browser-based workspace editor, where you can manage your software architecture model and diagrams.
Please see Help - Workspace Editor for usage information.
"Elements" provides a visual representation of the elements in the software architecture model.
Click an element to add a child underneath it, and right-click an element to modify it.
To rename the workspace, right-click the root node.
Static structure (top; people, software systems, containers and components) Deployment model (bottom; deployment nodes and container instances)
"Relationships" provides a visual summary of the relationships between the static structure elements in the model.
To create a relationship between two elements, click the source element, then click the destination element.
Right-click an element to modify its outbound relationships.
Alternatively, you can use the quick find feature (press Space) to select the relationship source and/or destination.
Filter elements
Scope
Tags
Filter relationships
Tags
There are no elements in this software architecture model - use Elements to create some.
x
"Views" allows you to manage the set of views and styles contained within the workspace. Use the buttons below to add, edit and delete views and styles.
There are no elements in this software architecture model - use Elements to create some.
See Help - Diagram editor for details of how to create, modify, and remove relationships using the diagram editor.
Relationships
Elements
Relationships
Element styles
Tag
Shape
Icon
Background
Stroke
Text
Width
Height
Font Size
Border
Opacity
Metadata
Description
Relationship styles
Tag
Color
Position
Thickness
Width
Font Size
Dashed
Opacity
Routing
"Perspectives" allows you to manage the perspectives associated with elements and relationships.
You can use the quick find feature (press Space) to find an element.
See Help - Perspectives for more details.
There are no elements in this software architecture model - use Elements to create some.
"Documentation" allows you to manage and edit the documentation that resides in the software architecture model.
Images
Drag and drop, or use the button below to import images (.jpg, .png, .gif)
"Decisions" allows you to manage and edit the decision records that resides in the software architecture model.
Theme
The theme feature lets you apply an existing set of element and relationship styles to diagrams.
See Help - Themes for more details.
Theme URLs
(a comma separated list of URLs, see Help - Themes for more details)
Branding
The branding feature lets you apply a font and logo to the diagrams and documentation.
See Help - Branding for more details.
Font name and URL
(the default font is Open Sans)
Logo
Terminology
By default, Structurizr uses the terminology defined by the C4 model when rendering elements on diagrams, although you can change it here (e.g. language translations).
See Help - Terminology for more details.
Metadata symbols
By default, Structurizr renders metadata between square brackets.
The workspace linking feature allows you to reuse elements from a linked workspace. See Workspace linking for more details.
Software System
A software system is the highest level of abstraction and describes something that delivers value to its users, whether they are human or not. This includes the software system you are modelling, and the other software systems upon which your software system depends (or vice versa).
In many cases, a software system is "owned by" a single software development team.
Person
A person represents one of the human users of your software system (e.g. actors, roles, personas, etc).
Container
Not Docker! In the C4 model, a container represents an application or a data store. A container is something that needs to
be running in order for the overall software system to work. In real terms, a container is something like:
Server-side web application: A Java EE web application running on Apache Tomcat, an ASP.NET MVC application running on Microsoft IIS, a Ruby on Rails application running on WEBrick, a Node.js application, etc.
Client-side web application: A JavaScript application running in a web browser using Angular, Backbone.JS, jQuery, etc.
Client-side desktop application: A Windows desktop application written using WPF, an OS X desktop application written using Objective-C, a cross-platform desktop application written using JavaFX, etc.
Mobile app: An Apple iOS app, an Android app, a Microsoft Windows Phone app, etc.
Server-side console application: A standalone (e.g. "public static void main") application, a batch process, etc.
Microservice: A single microservice, hosted in anything from a traditional web server to something like Spring Boot, Dropwizard, etc.
Serverless function: A single serverless function (e.g. Amazon Lambda, Azure Function, etc).
Database: A schema or database in a relational database management system, document store, graph database, etc such as MySQL, Microsoft SQL Server, Oracle Database, MongoDB, Riak, Cassandra, Neo4j, etc.
Blob or content store: A blob store (e.g. Amazon S3, Microsoft Azure Blob Storage, etc) or content delivery network (e.g. Akamai, Amazon CloudFront, etc).
File system: A full local file system or a portion of a larger networked file system (e.g. SAN, NAS, etc).
Shell script: A single shell script written in Bash, etc.
etc
A container is essentially a context or boundary inside which some code is executed or some data is stored.
And each container is a separately deployable/runnable thing or runtime environment, typically (but not always) running in its own process space.
Because of this, communication between containers typically takes the form of an inter-process communication.
Component
The word "component" is a hugely overloaded term in the software development industry, but in this context a component is a grouping of related functionality encapsulated behind a well-defined interface.
If you're using a language like Java or C#, the simplest way to think of a component is that it's a collection of implementation classes behind an interface. Aspects such as how those components are packaged (e.g. one component vs many components per JAR file, DLL, shared library, etc) is a separate and orthogonal concern.
An important point to note here is that all components inside a container typically execute in the same process space.
In the C4 model, components are not separately deployable units.
System Landscape view
The C4 model provides a static view of a single software system but, in the real-world, software systems never live in isolation.
For this reason, and particularly if you are responsible for a collection of software systems, it's often useful to understand how all of these software systems fit together within the bounds of an enterprise.
To do this, simply add another diagram that sits "on top" of the C4 diagrams, to show the system landscape from an IT perspective. Like the System Context diagram, this diagram can show
the organisational boundary, internal/external users and internal/external systems.
Essentially this is a high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. From a practical perspective, a system landscape diagram is really just a system context diagram without a specific focus on a particular software system.
The selected software system becomes the scope of the diagram, and is added to it automatically.
System Context view
A System Context diagram is a good starting point for diagramming and documenting a software system,
allowing you to step back and see the big picture. Draw a diagram showing your system
as a box in the centre, surrounded by its users and the other systems that it interacts with.
Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape.
The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies,
protocols and other low-level details. It's the sort of diagram that you could show to non-technical people.
Once you understand how your system fits in to the overall IT environment with a System Context diagram, a useful next step is to zoom-in to the system boundary with a Container diagram.
In the C4 model, a "container" is an application or data store; something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc.
Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data.
The Container diagram shows the high-level shape of the software architecture and how responsibilities
are distributed across it. It also shows the major technology choices and how the containers communicate
with one another. It's a high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
A Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details.
The selected element becomes the scope of the dynamic view, and determines the types of elements that can be added to the view as follows:
None: People and software systems.
Software System: People, other software systems, and containers.
Container: People, other software systems, other containers, and components within the selected container.
Dynamic view
A dynamic diagram can be useful when you want to show how elements in a static model collaborate at runtime to implement a user story, use case, feature, etc.
This dynamic diagram is based upon a UML communication diagram
(previously known as a "UML collaboration diagram"). It is similar to a UML sequence diagram
although it allows a free-form arrangement of diagram elements with numbered interactions to indicate ordering.
The selected software system becomes the scope of the deployment view, and determines the container instances that can be added to the view as follows:
None: All container instances within the deployment environment.
Software System: Only container instances in the deployment environment, belonging to the selected software system.
Deployment view
A deployment diagram allows you to illustrate how containers in the static model are mapped to infrastructure.
This deployment diagram is based upon a UML deployment diagram, although simplified slightly to show the mapping between containers and deployment nodes.
A deployment node is something like physical infrastructure (e.g. a physical server or device), virtualised infrastructure (e.g. IaaS, PaaS, a virtual machine), containerised infrastructure (e.g. a Docker container), an execution environment (e.g. a database server, Java EE web/application server, Microsoft IIS), etc. Deployment nodes can be nested.
This is a demonstration workspace.
Relationships
Views
Perspectives
Documentation
Decisions
Configuration
Workspace Linking
Static structure (top; people, software systems, containers and components)
Animation