The Kladde is now a whole system: domain modules, aggregates in Orleans grains, a sales pipeline with event sourcing, outbox and inbox over Service Bus, a cluster of two silos in Azure Container Apps. From module 4.8 come the threat model in docs/threat-model.md and the permissions table in docs/permissions.md. What is still missing is a look at the platform underneath: network, identity across several offices, high availability, disaster recovery, tenant model and governance. That is what module 4.7 is about.

Before you change any of it, look at the whole once with a fixed grid. Microsoft has the Well-Architected Framework for that: five pillars, a checklist each and a self-assessment that turns your answers into recommendations. In lesson 4.1.2 you already used the five pillars as a scaffold for your quality goals. Now you use the framework as a tool for a review. At the end of the lesson docs/well-architected-review.md is in the Kladde, the findings are ordered, and the three most important are issues in the repository.

Five pillars, five questions

Each pillar asks the system a question. The table maps them to your quality goals from docs/quality-goals.md:

Pillar The question for the system Checklist The Kladde's quality goal
Reliability Does it withstand faults, and does it come back after an outage within the agreed time? RE:01 to RE:10 Q3 Booking despite outages, Q4 Delivering and rolling back
Security Does it protect confidentiality, integrity and availability, even when one part has already been breached? SE:01 to SE:12 Q1 Several offices that never see each other
Cost Optimization Is what it costs in the right proportion to what it brings? CO:01 to CO:14 Q5 Cost per office
Operational Excellence Can it be delivered safely, observed and operated by people who don't have everything in their heads? OE:01 to OE:11 Q4, plus Q7 Fast tests
Performance Efficiency Does it grow with the load without being oversized? PE:01 to PE:12 Q2 Response time

Two of your goals, Q6 (the core knows no framework) and Q7 (fast tests), have no pillar of their own. That is not a flaw of the framework: It looks at the workload in the cloud, not at how the code is built. Changeability and testability appear there under operations, for instance as "safe deployment" or "standards for development", but less precisely than your architecture tests check them.

Each pillar has three parts that you find on Microsoft Learn:

  • Design principles: the pillar's principles, for reliability for example "design for business requirements, for resilience, for recovery, for operations, and keep it simple".
  • Checklist: ten to fourteen recommendations with an identifier like RE:03 and a detailed guide each. You use the identifiers in your review so that every row leads to its source.
  • Tradeoffs: what a recommendation of this pillar costs in the other pillars.

On top of that come the service guides, one for each Azure service. For the Kladde the most important are those for Azure Container Apps, Azure SQL Database, Service Bus and Key Vault. They translate the pillars into settings of a service, such as "at least two replicas" or "turn on zone redundancy".