The set of static building blocks that Structurizr uses to describe a software system can be summarised as follows.
A software system is made up of one or more containers (web applications, mobile apps, standalone applications, databases, file systems, etc), each of which contains one or more components, which in turn are implemented by one or more classes (or code).
Here is a definition of these building blocks.
|Container||A Software System||
|Code Element||A Component||
- All elements must have a name.
- All elements must be named uniquely within the context of their parent scope.
However you think about your users (as actors, roles, personas, etc), people are the various human users of your software system.
People are represented by adding
Person objects to your software architecture model, with the following properties:
- Name: The name of the person, user, role, actor or persona.
- Description: A short description of the person, their role, responsibilities, etc.
- Location: The location of the person, relative to the context of the software system -
This is how a person is visualised without any styling.
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.
Software systems are represented by adding
SoftwareSystem objects to your software architecture model, with the following properties:
- Name: The name of the software system.
- Description: A short description of the software system, its responsibilities, etc.
- Location: The location of the software system, relative to the context of the software system being modelled -
This is how a software system is visualised without any styling.
A container represents something that hosts code or data. 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 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.
- 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.
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 thing.
Containers are represented by adding
Container objects to a software system in your software architecture model, with the following properties:
- Name: The name of the container.
- Technology: The implementation technology (e.g. Spring MVC web application, MySQL, etc).
- Description: A short description of the container, its responsibilities, etc.
This is how a container is visualised without any styling.
The word "component" is a hugely overloaded term in the software development industry, but in this context a component as simply being 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.
Components are represented by adding
Component objects to a container in your software architecture model, with the following properties:
- Name: The name of the component.
- Technology: The implementation technology (e.g. Java, Spring Bean, etc).
- Description: A short description of the component, its responsibilities, etc.
This is how a component is visualised without any styling.