Add additional layer to nav for Physical Architecture

docs/architecture/Index.md → docs/architecture.md

@@ -4,6 +4,7 @@ title: Architecture
 nav_order: 4
 has_children: true
 ---
+## Architecture
 
 ## Architecture
 
@@ -17,7 +18,7 @@ standards: [NHS Architecture Principles][nhsap] | [Software Engineering Quality
 
 [rmc]:https://transform.england.nhs.uk/information-governance/guidance/records-management-code/
 
-## General principles for diagrams
+### General principles for diagrams
 
 * Pages are structured using the [4+1 View of Architecture][Kruchten]
   and flow from high level to broken down functionality.
@@ -31,12 +32,11 @@ standards: [NHS Architecture Principles][nhsap] | [Software Engineering Quality
   4. provide context on which part of the system the diagram relates
      to
 
-![img.png](assets/kruchten_4_1_model.png)
-
-[<figcaption>Architectural Blueprints—The “4+1” View Model of Software Architecture</figcaption>][Kruchten]
+![img.png](architecture/assets/kruchten_4_1_model.png)
+[Architectural Blueprints—The “4+1” View Model of Software Architecture][Kruchten]
 
 [Kruchten]: https://ics.uci.edu/~michele/Teaching/INF117/Krutchten%204+1View%20SWArch.pdf
 
 * Physical
-  * [Sub-domains and bounded contexts](physical/sub-domains_and_bounded_contexts)
-  * [Initial account structure for new architecture](physical/initial_account_structure_for_new_architecture)
+  * [Sub-domains and bounded contexts](architecture/physical/sub-domains_and_bounded_contexts)
+  * [Initial account structure for new architecture](architecture/physical/initial_account_structure_for_new_architecture)

docs/architecture/1_logical.md

@@ -0,0 +1,9 @@
+---
+layout: default
+title: Logical View
+parent: Architecture
+nav_order: 1
+has_children: true
+published: false
+---
+## Logical View

docs/architecture/2_development.md

@@ -0,0 +1,9 @@
+---
+layout: default
+title: Development View
+parent: Architecture
+nav_order: 2
+has_children: true
+published: false
+---
+## Development View

docs/architecture/3_process.md

@@ -0,0 +1,9 @@
+---
+layout: default
+title: Process View
+parent: Architecture
+nav_order: 3
+has_children: true
+published: false
+---
+## Process View

docs/architecture/4_physical.md

@@ -0,0 +1,12 @@
+---
+layout: default
+title: Physical View
+parent: Architecture
+nav_order: 4
+has_children: true
+---
+## Physical View
+
+> The physical view, ... describes the mapping(s) of the software onto the hardware and reflects its
+distributed aspect
+

docs/architecture/5_scenarios.md

@@ -0,0 +1,9 @@
+---
+layout: default
+title: Scenarios
+parent: Architecture
+nav_order: 5
+has_children: true
+published: false
+---
+## Scenarios

docs/architecture/physical/initial_account_structure_for_new_architecture.md

@@ -1,8 +1,9 @@
 ---
 layout: default
 title:  Initial account structure for new architecture
-parent: Architecture
+parent: Physical View
 ---
+## Initial account structure for new architecture
 
 ## Initial account structure for new architecture
 

docs/architecture/physical/sub-domains_and_bounded_contexts.md

@@ -1,13 +1,14 @@
 ---
 layout: default
 title:  Sub-domains and bounded contexts
-parent: Architecture
+parent: Physical View
 ---
+## Sub-domains and bounded contexts
 
 ## Sub-domains and bounded contexts
 
 [Bounded contexts][1] are a pattern used in DDD to model parts of a
-system which operate on a single consistent model of part of a
+system which operate on a single "unified" model of part of a
 business domain.
 
 [1]: https://martinfowler.com/bliki/BoundedContext.html
@@ -33,8 +34,5 @@ accounts and components which are deployed within them.
   * Each microservice should be individually deployable with defined
     contracts between services
   * Each microservice should be contained in its own GitHub repo
-* Questions:
-  * Where are audit logs kept? Per sub-domain, or shared location in
-    isolated account?
 
 ![Bounded Context Diagram](assets/Bounded_Context.drawio.png)