In this module, you will learn how to:
- Define a
container - Enrich a
software modelwithtechnology - Visualize a new level, the
containerone, akaC4.2
⌛ Estimated time to complete: 15 min
✏️ Locate MILA software system, and start typing container within.
As expected, Cornifer fuels accordingly:
identifier = container "name" "description" "technology" "tags" {}
Name, description & tags are well-known players but a brand-new dimension, the technology one, appears. Take the opportunity to leverage this dimension to enrich your model, providing dedicated insights such as Blazor or MongoDB to qualify underlying technology stack.
✏️ Fill in the different placeholders.
📙 REVEAL THE ANSWER
mila = softwareSystem "MILA" "Provides [...]" "" {
+ spa = container "Web application" "Provides [...]" "Blazor" "#web" {
+ }
+ mobile = container "Mobile application" "Provides [...]" "Xamarin" "#mobile" {
+ }
+ api = container "API application" "Extracts [...]" "" "" {
+ }
+ store = container "Materials store" "Stores [...]" "MongoDB" "#db" {
+ }
}You may notice that we do not provide technology for the api container. It is fine. Sometime you do not have all the information. Sometime, choice has not been made yet. Remember, modern architecture is not an all-in upfront one. It will be refined along the way. Good news, your software model lands in your code base, and thus can benefit same facilities, such as incremental update, facilitated diff, ... Your software model is alive. It evolves. It morphes. And, it is an healhty behavior.
✏️ Do not forget to update the relationships section.
Cornifer comes in with built-in Intellisense to speed up DSL edition:
📙 REVEAL THE ANSWER
model {
matt -> mila "sends pictures to" "" ""
+ matt -> mila.spa "uses" "" ""
+ matt -> mila.mobile "uses" "" ""
simon -> icarus "uses" "" ""
icarus -> mila "fetches materials from" "" ""
+ icarus -> mila.store "fetches materials from" "" ""
+ mila.spa -> mila.api "makes API call to" "" ""
+ mila.mobile -> mila.api "makes API call to" "" ""
+ mila.api -> mila.store "stores materials to" "" ""
}✏️ Add the view we are interested in, leveraging Cornifer, by typing container within views section:
📙 REVEAL THE ANSWER
views {
+ # C4.2
+ container mila "Container" "" {
+ include *
+ autoLayout
+ }
}✏️ To avoid ending up with default, one can amend theming to take into account new players:
📙 REVEAL THE ANSWER
views {
styles {
+ element "Container" {
+ background #FFD9D9
+ stroke #C92D39
+ strokeWidth 8
+ }
+
+ element "#web" {
+ shape WebBrowser
+
4165
}
+ element "#db" {
+ shape Cylinder
+ }
+ element "#mobile" {
+ shape MobileDevicePortrait
+ }
}
}✏️ Save your workspace, and refresh the browser.
Notice how tags once again allow us to slightly change the display, speeding up the visual inspection e.g. smartphone & browser shapes.
Coming from System Context diagram, imagine you deep dived within the MILA blue box. A system is composed by container(s) - think executable granularity such as desktop app, web app, backend, database...
- A dashed bounding box stresses parent
software systemboundary. - Involved
person& externalsoftware systemare still presents and help us to refine which internal parts are coupled. One could notice thatAPIapplication is totally agnostic ofMILAsystem I/O. - Two entry points with asymmetric facilities & different form factors to interact with our application from an end-user perspective...
- … both leveraging - through gRPC - a back-end service for post-processing...
- … which in turn persists enriched data into some storage area.
- Starting from container cardinality & heterogeneity, we are able to sketch how one could deploy the application, organize both source code control & backlog, and tailor team(s) accordingly.
📘 Completing this stage should lead to this final workspace.
We learn how to tackle the container level, starting refining technical proposal by introducing technology. As usual, theming is there to enhance views, and make downstream reading smarter.
Let's see how to replicate this approach in next stage.