🎯 Learning objectives

• I can define an application class as an ASR bundle and write it as R(a) = (w; S(a); K(a)).
• I can derive a class's High weights from documented challenges and binding scenarios, each H a veto trigger.
• I can place C1–C5 on the map of ten classes by workload shape and consistency semantics.
• I know the binding scenarios, High weights, shape S(a) and constraints K(a) of classes C1 to C5.
• I can explain, with LMAX and Monzo, why R(a) defines a feasible set rather than one pattern.
• I can explain why C2 scales reads from a monolith yet moves to EDA+MS at measured organisational scale.
• I can explain why D8 = H and D10 = H jointly veto premium-priced structures in C3.
• I can explain why cross-module ACID binds C4 to one transactional quantum and makes MS the strongest anti-fit.
• I can explain C5's hybrid consistency as a designed boundary that belongs in an ADR.
• I can judge where an AI component may live in a topology by its latency class, not its accuracy.

🧑‍🏫 Theory

Lecture 8: Requirements Profiles I – Application Classes C1–C5 · 3 lessons lecture + 1 lesson standup/coaching
Part III turns to the demand side: the requirements profiles of application classes C1–C5, derived from documented challenges and binding scenarios – every closing verdict a preview for Part IV.

• An application class is an ASR bundle, not an industry label: R(a) = (w; S(a); K(a)) – weights from the (H,H) leaves, S(a) gates the core, K(a) knocks out before scoring.
• A weight is a compressed empirical claim, made auditable per class: documented challenges → binding scenarios with response measures → High weights; an H is a veto trigger, not a coefficient.
• Regulation translates directly into structure (immutable journals, scope zoning); one organisation runs several classes, so the matrix is read per subsystem; classifying a system is a hypothesis, never a verdict.
• The map of ten classes: workload shape × consistency semantics; C1–C5 all interactive – C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual; C1 and C2 form the mirror pair.
• C1 core banking: D4/D5/D6/D7/D9 High, densest K(a); LMAX vs. Monzo – R(a) defines the feasible set, constraints decide within it; AI at the edge: agents propose, deterministic services decide and book.
• C2 social media: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day – a monolith is an organisational problem, not a read-scaling problem.
• C3 back-office, the modal case: ca. 60 % of life-cycle cost is evolution (D7 = H); D8 = H and D10 = H jointly veto premium-priced structures; verdict MM, workflow engine behind a port.
• C4 ERP: integration is the product – cross-module ACID postings bind the class to one transactional quantum; MM the strongest alignment in the matrix, MS's −− on D4 the strongest anti-fit.
• C5 e-commerce: quality attributes with price tags, 10–50× peaks, hybrid consistency as a designed boundary, PCI DSS v4.0 scope minimisation as structure; Shopify vs. Amazon – team size, not traffic, decides.
• Side by side: D7 High in all five, D8/D10 High only in C3; verdict previews C1 MM+HX, C2 EDA+MS at measured organisational scale, C3/C4/C5 MM – Part IV recomputes every verdict.

📎 Materials: Slide set of Lecture 8 (added below by the lecturer) · Script: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).

Also before the lecture:

• Sprint 1 / M3 starts this week: bring the walking-skeleton plan from your A2 dossier (MarketDataService + minimal ResearchAgent + stable API).
• Make sure Deliverable A2 and the design-review gate are complete – production code starts only after the gate (exploratory spikes are allowed).
• Have the 7 × 10 matching matrix from Lecture 7 at hand: this week derives its rows C1–C5 from the demand side.

🧩 Exercise session: The exercise slot becomes a one-lesson standup/coaching session as the implementation phase begins with Sprint 1 of the walking skeleton (M3); implementation happens mainly in self-study time.

🛠️ Project work this week · Milestone M3 – Walking Skeleton (weeks 8–9)

• Start the walking skeleton (Sprint 1, M3) first thing in the implementation phase: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, plus a stable API and a placeholder UI that calls it.
• Keep the deterministic core free of LLM calls – agents propose, deterministic services decide and book; this is the line that is graded. Your deterministic services inherit the C3 verdict: ACID, boring on purpose.
• Use a snapshot of market/news data so that demo and grading are reproducible.
• Commit after each milestone and record architectural decisions as ADRs as you go.
• Work towards the week-9 check: the walking skeleton runs end-to-end (M3).

No deliverable is due this week.