Deliverables

The curriculum covers what an architect should know. This covers what an architect actually hands over: 55 artifacts, each with a worked example, a note on when it is worth producing, who reads it, and the ways it usually goes wrong. Filter by the artifact's type, the kind of engagement that calls for it, the stack or industry it is drawn against, or the audience it is written for.

Identify the deliverable → 42 diagrams, shown one at a time with the answer withheld. Nothing to submit.

4 of 55 deliverables shown.

flowchart LR
  subgraph t1[" "]
    direction TB
    c1["cmd: Place Order"]
    e1["OrderPlaced<br/><i>fact</i>"]
    r1[("read: Order Status")]
    c1 --> e1 --> r1
  end
  subgraph t2[" "]
    direction TB
    c2["cmd: Authorise Payment"]
    e2["PaymentAuthorised<br/><i>fact</i>"]
    r2[("read: Payment Ledger")]
    c2 --> e2 --> r2
  end
  subgraph t3[" "]
    direction TB
    c3["policy: on PaymentAuthorised<br/>allocate stock"]
    e3["StockAllocated<br/><i>fact</i>"]
    r3[("read: Availability")]
    c3 --> e3 --> r3
  end
  subgraph t4[" "]
    direction TB
    c4["policy: on StockAllocated<br/>request despatch"]
    e4["ConsignmentCreated<br/><i>fact</i>"]
    r4[("read: Tracking")]
    c4 --> e4 --> r4
  end
  e1 --> c2
  e2 --> c3
  e3 --> c4

Behavioural View

Event Model

The business as a sequence of facts that happened, with the command that caused each and the read models and reactions it feeds.

Event-Driven Architecture Design

flowchart TB
  subgraph fwd["Forward path"]
    direction LR
    f1["1. Reserve stock"] --> f2["2. Authorise payment"] --> f3["3. Create consignment"] --> f4["4. Capture payment"] --> f5["5. Despatch"]
  end
  subgraph comp["Compensation"]
    direction RL
    k1["Release stock"] --- k2["Void authorisation"] --- k3["Cancel consignment"] --- k4["Refund<br/><i>visible to customer</i>"]
  end
  f1 -.->|"undo"| k1
  f2 -.->|"undo"| k2
  f3 -.->|"undo"| k3
  f4 -.->|"undo"| k4
  f5 -.->|"no undo — goods have left"| x(["point of no return"])

Behavioural View

Saga Compensation Flow

A multi-service transaction as forward steps each paired with an undo, showing where the sequence becomes irreversible.

Sagas & Compensation Design

sequenceDiagram
  autonumber
  participant C as Client
  participant G as API Gateway
  participant O as Order Service
  participant P as Payment Gateway
  participant Q as Event Log

  C->>G: POST /orders (Idempotency-Key)
  G->>O: create order
  O->>O: persist as PENDING
  O->>P: authorise (deadline 3s)
  alt authorised
    P-->>O: approved + auth id
    O->>O: mark CONFIRMED
    O->>Q: OrderConfirmed
    O-->>G: 201 Created
  else declined
    P-->>O: declined
    O->>O: mark REJECTED
    O-->>G: 402 Payment Required
  else timeout
    P--xO: no response by deadline
    O->>O: keep PENDING
    O-->>G: 202 Accepted (poll for status)
    Note over O,P: reconciliation job settles<br/>PENDING against the provider
  end
  G-->>C: response

Behavioural View

Sequence Diagram

One scenario as an ordered exchange of messages between participants, with time on the vertical axis and the failure paths drawn rather than assumed.

Sequence Diagrams Design

stateDiagram-v2
  [*] --> Pending: order placed
  Pending --> Authorised: payment approved
  Pending --> Rejected: payment declined
  Pending --> Expired: no response in 24h
  Authorised --> Picking: stock allocated
  Authorised --> Cancelled: customer cancels
  Picking --> Shipped: consignment handed to carrier
  Picking --> Backordered: stock unavailable
  Backordered --> Picking: stock replenished
  Backordered --> Cancelled: customer cancels
  Shipped --> Delivered: carrier confirms
  Shipped --> Lost: no scan in 14 days
  Delivered --> Returned: return accepted
  Rejected --> [*]
  Expired --> [*]
  Cancelled --> [*]
  Delivered --> [*]
  Returned --> [*]
  Lost --> [*]

Behavioural View

State Machine Diagram

The legal states of one entity and the events that move it between them, which is where illegal transitions become visible.

Architecture Diagrams Design