Closes #10.

abstractions/11-microservices.md

@@ -16,13 +16,13 @@ what you mean by "microservice". With that in mind, let's start from the beginni
 Imagine that we work for a small cash-strapped startup company and our task is to build a software system (named "X")
 that offers business capabilities A, B, and C to our customers. Our system context diagram might look like this:
 
-![](/images/microservices/1.png)
+[![](/images/microservices/1.png)](/images/microservices/1.png)
 
 Arguably the quickest and cheapest way to get something delivered, especially as a cash-strapped startup with a
 small engineering team, is to use a monolithic architecture, consisting of a single monolithic web application
 reading from and writing to a single monolithic database schema. The resulting container diagram looks like this:
 
-![](/images/microservices/2.png)
+[![](/images/microservices/2.png)](/images/microservices/2.png)
 
 ## Stage 2 - microservices architectural style
 
@@ -42,13 +42,13 @@ To help us align this with the C4 model, let's substitute "application" for "sof
 In this stage of our startup's journey, although we've hired a few more engineers, we've decided to stay
 as a single team. Our system context diagram remains the same:
 
-![](/images/microservices/3.png)
+[![](/images/microservices/3.png)](/images/microservices/3.png)
 
 But our container diagram has changed. We've decided to retain the single monolithic UI of the existing
 web application, but move the business logic and data into individual microservices. The resulting container diagram
 now looks like this:
 
-![](/images/microservices/4.png)
+[![](/images/microservices/4.png)](/images/microservices/4.png)
 
 As we're still a single engineering team, transitioning to a microservices architecture is an implementation detail
 that is only apparent inside the team boundary. This is why all seven containers are shown inside the software system 
@@ -58,17 +58,17 @@ Instead, this version of the diagram uses colour coding the show the relationshi
 schema containers. If you wanted to be more explicit about this pairing, you could draw a box around each pair to
 show they are grouped together.
 
-![](/images/microservices/5.png)
+[![](/images/microservices/5.png)](/images/microservices/5.png)
 
 Imagine now that we are going to expand the scope of our software system to also include business capability D.
 The revised system context diagram would look like this:
 
-![](/images/microservices/6.png)
+[![](/images/microservices/6.png)](/images/microservices/6.png)
 
 And if that new business capability was implemented by a new microservice, which is just a single stateless AWS lambda,
 the revised container diagram would look like this:
 
-![](/images/microservices/7.png)
+[![](/images/microservices/7.png)](/images/microservices/7.png)
 
 ## Stage 3 - Conway's Law
 
@@ -87,19 +87,19 @@ We can now use the C4 model to look at each software system from the perspective
 with each service being "promoted" from a pairing of containers into a software system. The system
 context diagram for team X now looks like this:
 
-![](/images/microservices/8.png)
+[![](/images/microservices/8.png)](/images/microservices/8.png)
 
 Team X has only retained the monolithic UI, so the revised container diagram for software system X looks like this:
 
-![](/images/microservices/9.png)
+[![](/images/microservices/9.png)](/images/microservices/9.png)
 
 And from the perspective of team A, the system context diagram for service A looks like this:
 
-![](/images/microservices/10.png)
+[![](/images/microservices/10.png)](/images/microservices/10.png)
 
 And the container diagram for service A looks like this:
 
-![](/images/microservices/11.png)
+[![](/images/microservices/11.png)](/images/microservices/11.png)
 
 ## Summary
 

introduction.md

@@ -13,8 +13,8 @@ developer to communicate the software architecture of a software system using di
 confused mess of boxes and lines ... inconsistent notation (colour coding, shapes, line styles, etc), ambiguous naming,
 unlabelled relationships, generic terminology, missing technology choices, mixed abstractions, etc.
 
-| ![A software architecture sketch](/images/sketch-1.jpg) | ![A software architecture sketch](/images/sketch-2.jpg) |
-| ![A software architecture sketch](/images/sketch-3.jpg) | ![A software architecture sketch](/images/sketch-4.jpg) |
+| [![A software architecture sketch](/images/sketch-1.jpg)](/images/sketch-1.jpg) | [![A software architecture sketch](/images/sketch-2.jpg)](/images/sketch-2.jpg) |
+| [![A software architecture sketch](/images/sketch-3.jpg)](/images/sketch-3.jpg) | [![A software architecture sketch](/images/sketch-4.jpg)](/images/sketch-4.jpg) |
 
 As an industry, we do have the Unified Modeling Language (UML), ArchiMate and SysML, but asking whether these provide
 an effective way to communicate software architecture is often irrelevant because many teams have already thrown them
@@ -28,15 +28,15 @@ both during up-front design sessions and when retrospectively documenting an exi
 "maps of your code", at various levels of detail, in the same way you would use something like Google Maps to zoom in
 and out of an area you are interested in.
 
-| ![](/images/map-4.jpg) | ![](/images/map-3.jpg) | ![](/images/map-2.jpg) | ![](/images/map-1.jpg) |
-| ![](https://static.structurizr.com/workspace/36141/diagrams/SystemContext.png) | ![](https://static.structurizr.com/workspace/36141/diagrams/Containers.png) | ![](https://static.structurizr.com/workspace/36141/diagrams/Components.png) | ![](https://static.structurizr.com/workspace/36141/diagrams/MainframeBankingSystemFacade.png) |
+| [![](/images/map-4.jpg)](/images/map-4.jpg) | [![](/images/map-3.jpg)](/images/map-3.jpg) | [![](/images/map-2.jpg)](/images/map-2.jpg) | [![](/images/map-1.jpg)](/images/map-1.jpg) |
+| [![](https://static.structurizr.com/workspace/36141/diagrams/SystemContext.png)](/diagrams/system-context) | [![](https://static.structurizr.com/workspace/36141/diagrams/Containers.png)](/diagrams/container) | [![](https://static.structurizr.com/workspace/36141/diagrams/Components.png)](/diagrams/component) | [![](https://static.structurizr.com/workspace/36141/diagrams/MainframeBankingSystemFacade.png)](/diagrams/code) |
 | Level 1: A [system context diagram](/diagrams/system-context) provides a starting point, showing how the software system in scope fits into the world around it. | Level 2: A [container diagram](/diagrams/container) zooms into the software system in scope, showing the applications and data stores inside it. | Level 3: A [component diagram](/diagrams/component) zooms into an individual container, showing the components inside it. | Level 4: A [code diagram](/diagrams/code) (e.g. UML class) can be used to zoom into an individual component, showing how that component is implemented at the code level. |
 
 ## Improving diagramming maturity
 
 The goal of the C4 model is to raise the level of maturity associated with software architecture diagrams.
 
-![](/images/software-architecture-diagramming-maturity-model.png)
+[![](/images/software-architecture-diagramming-maturity-model.png)](/images/software-architecture-diagramming-maturity-model.png)
 
 <script type="application/javascript" src="https://code.jquery.com/jquery-3.7.1.slim.min.js"></script>
 <script type="application/javascript" src="/assets/c4model.js"></script>