ANALYSIS asked WHAT. DESIGN asks HOW. Concretely, five things change. 1. THE MODEL GAINS SOFTWARE CLASSES. The conceptual model contained only domain concepts. The design model adds the classes that make a running system: controllers, repositories, factories, adapters, gateways, view/presentation classes, configuration None of these has a domain counterpart, and none belongs in analysis. 2. RESPONSIBILITIES ARE ASSIGNED. Analysis said "a Payment was created and associated with the Application". Design says WHICH OBJECT does the creating and WHICH holds the reference. This is the central design activity and the subject of the patterns topic. 3. VISIBILITY IS DECIDED. For object A to send a message to object B, A must be able to SEE B. Analysis associations are undirected; design must decide who holds a reference to whom, and how they got it. 4. TYPES, SIGNATURES AND EXCEPTIONS APPEAR. `approve()` becomes `approve(officer : OfficerId) : void throws IllegalTransitionException`. 5. NON-FUNCTIONAL REQUIREMENTS ENTER. The supplementary specification — response times, availability, security — had no expression in the use case model. Now it drives layering, caching, transaction boundaries and error handling. THE TWO CENTRAL DESIGN OUTPUTS, produced together and iteratively: INTERACTION DIAGRAMS sequence or communication diagrams showing which objects collaborate to realise each system operation DESIGN CLASS DIAGRAM the classes, with types, visibility, method signatures and navigable associations THE ORDER MATTERS AND IS COUNTER-INTUITIVE: DRAW THE INTERACTIONS FIRST, then read the class diagram off them. Deciding the interactions is what determines which methods each class needs — a message sent to an object IS a method on that object. Teams that draw the class diagram first invent methods speculatively and then find the collaborations do not need them. THE INPUTS TO DESIGN, all from ACtE0804: use cases → what interactions must be supported system operations → the entry points; each becomes a (from the SSDs) controller method operation contracts → what each interaction must achieve, as postconditions domain model → the source of most design classes supplementary spec → the non-functional constraints glossary → the names to use

THE STANDARD LAYERED ARCHITECTURE for an OO application — the same layered organisation from ACtE0802, applied here: ┌─────────────────────────────────────┐ │ UI / PRESENTATION │ windows, screens, │ │ reports, API │ │ endpoints ├─────────────────────────────────────┤ │ APPLICATION / SERVICE │ coordinates use │ │ cases, transaction │ │ boundaries ├─────────────────────────────────────┤ │ DOMAIN │ the business │ │ concepts AND their │ │ behaviour ├─────────────────────────────────────┤ │ TECHNICAL SERVICES / INFRASTRUCTURE │ persistence, │ │ logging, messaging, │ │ security └─────────────────────────────────────┘ THE RULES: · a layer may depend on layers BELOW it, never above · the UI contains NO business logic — a rule broken constantly, and the reason is that it is convenient in the short term · the DOMAIN layer must not depend on the UI or on persistence. This is what makes the domain testable without a database and portable across UI technologies. THE DEPENDENCY INVERSION PROBLEM: the domain needs to save things, but saving is infrastructure, which is below it — so a direct call would be fine. But the domain must not depend on a specific database technology. THE SOLUTION: the domain declares an INTERFACE (`ApplicationRepository`) and infrastructure implements it. The dependency arrow is inverted, and the domain depends only on its own abstraction. domain: interface ApplicationRepository infrastructure: class PostgresApplicationRepository implements ApplicationRepository This is the Dependency Inversion principle, and it is why the interface lives in the domain package rather than beside its implementation — a detail that trips people up. THE ANAEMIC DOMAIN MODEL — the failure this layering is meant to prevent, and worth seeing side by side: ✗ ANAEMIC — domain classes are data holders class Application { getStatus(); setStatus(s); getFee(); setFee(f); // getters and setters only } class ApplicationService { approve(app, officer) { if (app.getStatus() != APPROVED_PENDING) throw… if (app.getReviewedBy().equals(officer)) throw… app.setStatus(APPROVED); app.setApprovedBy(officer); } } The rules live OUTSIDE the object that owns the data. Any other service can call setStatus(ISSUED) and bypass every rule — the invariants are unenforceable. ✔ RICH — behaviour lives with the data class Application { private Status status; private OfficerId reviewedBy; void approve(OfficerId officer) { assertTransition(APPROVED); if (officer.equals(reviewedBy)) throw new SeparationOfDutiesException(); this.status = APPROVED; this.approvedBy = officer; } } There is NO setStatus. The only way to reach APPROVED is through approve(), which enforces the rules. The invariant is now impossible to violate from outside. THE TEST FOR ANAEMIA: does the class have setters for the fields that carry business rules? If so, the rules are elsewhere and can be bypassed.

TAKE the contract from ACtE0804 and design the collaboration. INPUT — the contract: OPERATION recordPayment(applicationNo, amount, method) PRE the Application exists, is APPROVED, has no Payment POST a Payment was created with amount, method, time; associated with the Application and the Officer; a Receipt was created and associated with the Payment; no other Application was modified STEP 1 — WHERE DOES THE OPERATION ARRIVE? Each system operation needs a CONTROLLER: the first object beyond the UI layer that receives it. Two legitimate choices: a FAÇADE CONTROLLER — one per subsystem (LicenceSystemController) a USE CASE CONTROLLER — one per use case (IssueLicenceHandler) CHOOSE THE USE CASE CONTROLLER WHEN a façade would become bloated with dozens of unrelated operations — which is the high-fan-out, low-cohesion problem from the design heuristics topic. Here: `RecordPaymentHandler`. STEP 2 — WHO KNOWS WHAT? Walk each postcondition and ask which object holds the information needed: "is APPROVED, has no Payment" → the Application knows its own state → IT validates "amount equals the fee due" → the Application knows its fee → IT validates "a Payment was created" → who has the information to initialise it? The Application (it knows the amount owed) or the handler (it has the officer). Either is defensible; the Application creating it keeps the invariant "a payment matches the fee" inside the object. "a Receipt was created" → rendering is presentation, so a ReceiptFactory or service, NOT the domain "persisted" → the repository STEP 3 — THE INTERACTION: :RecordPaymentHandler │ │ 1. app := find(applicationNo) ├──────────────▶ :ApplicationRepository │ │ 2. payment := app.recordPayment(amount, method, officer) ├──────────────▶ :Application │ │ 2.1 assertPayable(amount) │ │ 2.2 «create» :Payment │ │ 2.3 this.payment := payment │ │ 3. save(app) ├──────────────▶ :ApplicationRepository │ │ 4. receipt := create(payment) ├──────────────▶ :ReceiptFactory │ │ 5. return receipt STEP 4 — READ THE CLASS DIAGRAM OFF THE INTERACTION. Every message becomes a method: RecordPaymentHandler + handle(no : String, amount : Money, method : PaymentMethod, officer : OfficerId) : Receipt - repository : ApplicationRepository - receipts : ReceiptFactory Application + recordPayment(amount : Money, method : PaymentMethod, officer : OfficerId) : Payment throws NotPayableException - assertPayable(amount : Money) : void - payment : Payment {0..1} «interface» ApplicationRepository + find(no : String) : Application + save(app : Application) : void NOTE WHAT DID NOT APPEAR: no `setStatus`, no `setPayment`, no `ApplicationManager`. The methods that exist are exactly the messages the collaboration sends — which is why interactions are drawn first. STEP 5 — CHECK AGAINST THE NON-FUNCTIONAL REQUIREMENTS: · the whole operation must be ONE TRANSACTION (money and state must not diverge) → the transaction boundary is the handler, which is why the application/service layer exists at all · the audit entry from the contract must be immutable → appended, never updated · p95 under 2 s → one repository read, one write; no further external calls on this path THE WHOLE POINT OF THE EXERCISE: the design was DERIVED from the contract, postcondition by postcondition, rather than invented. Each "who knows what?" question has a defensible answer, and where two answers were defensible the choice was made on which one keeps an invariant inside an object.