AISE502/moodle/week_04.html

<!-- ==========================================================================
     AISE502 · Moodle course page · Week 4
     Section title (Edit section → Section name): Week 4: Patterns I – Layered, Modular Monolith, Hexagonal
     Three blocks follow, matching the FHGR section template. Paste each block into the
     corresponding 'Text and media area' (editor → source code view), or all three into one.
     The slide set of lecture 4 is added by the lecturer as a file resource below block 2.
     Generated by src/build_moodle.py from src/content/week_04.json – edit the JSON, not this file.
     ========================================================================== -->

<!-- BLOCK 1 · Learning objectives -->
<h4>🎯 Learning objectives</h4>
<ul>
  <li>I can derive a capability profile C(p) from a pattern's problem and topology, with a structural reason per cell.</li>
  <li>I know the vocabulary of the three patterns: architecture quantum, technical versus domain partitioning, bounded context, ports and adapters.</li>
  <li>I can explain why L rates ++ on D4, D8, D10 yet pays on every axis of change and scale.</li>
  <li>I can read the MM column against L and show what domain partitioning buys at constant quantum count.</li>
  <li>I can explain why boundary conformance in a modular monolith must be a CI subject, not a diagram convention.</li>
  <li>I know the hexagonal dependency rule: adapters depend on ports, the core depends on nothing outside itself.</li>
  <li>I can explain why an HX port is the anti-corruption layer that makes an LLM component swappable and mockable.</li>
  <li>I can judge which of L, MM or MM+HX carries a requirements profile, using the selection signals.</li>
</ul>

<!-- BLOCK 2 · Theory -->
<h4>🧑‍🏫 Theory</h4>
<p><strong>Lecture 4: Patterns I – Layered, Modular Monolith, Hexagonal</strong> · 2 lessons lecture + 2 lessons exercise<br>
This lecture opens Part II and derives the capability profiles of L, MM and HX inductively – problem, topology, twelve dimensions, engineering consequences, and open-source systems to build and study.</p>
<ul>
  <li>L partitions a system into horizontal technical layers with a downward dependency rule; the whole system is exactly one architecture quantum – one unit of deployment, scaling and failure.</li>
  <li>L buys the lowest entry cost in the catalogue (++ on D4, D8, D10) and pays on every axis of change and scale – a specific trade, not a defect.</li>
  <li>MM keeps one deployable but partitions its interior by domain: each module owns one bounded context and its data and communicates only through published module APIs or in-process events.</li>
  <li>Against L at constant quantum count, MM's domain cut lifts D7 and D9 from − to + while D4 and D10 stay ++; the price is permanent boundary governance.</li>
  <li>Boundary conformance is a CI subject (ArchUnit, Spring Modulith, Packwerk), not a matter of good intentions; the default: domain partitioning now, distribution only when a measured requirement demands it.</li>
  <li>HX organises dependencies: the core defines technology-neutral ports, adapters plug in, all source-code dependencies point inwards; not a distribution style but a delta profile that composes with the other six.</li>
  <li>HX's delta: ++ on D7 (technology migrations become localised adapter tasks), D9 (hermetic domain tests) and D12 (an imposed anti-corruption layer for LLM components), bought with − on D8.</li>
  <li>L → MM isolates the partitioning axis and HX composes on top: the hexagonal modular monolith won last week's C10 mini-match and is the project's architecture.</li>
</ul>
<p>📎 <strong>Materials:</strong> Slide set of Lecture 4 <em>(added below by the lecturer)</em> · Script: Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).</p>

<!-- BLOCK 3 · Self-study and assignments -->
<h4>🧑‍💻 Self-study and assignments</h4>
<p><strong>📖 Reading before the lecture:</strong> Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).</p>
<p><strong>Also before the lecture:</strong></p>
<ul>
  <li>Bring the finalised R(platform) from Deliverable A1 (weights, workload shape, knock-out constraints) – this week's exercise shortlists L, MM and MM+HX against it.</li>
</ul>
<p><strong>🧩 Exercise session:</strong> Architecture study I (2 lessons): the teams inspect Apache Fineract and cosmicpython/code for boundaries and ports, shortlist L, MM or MM+HX for the platform core against R(platform) from A1, and draft the C4 context and container diagrams.</p>
<p><strong>🛠️ Project work this week</strong> · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)</p>
<ul>
  <li>Inspect Apache Fineract (34 fineract-* Gradle modules composed into one deployable, plus a custom/ extension directory) and cosmicpython/code (domain/, service_layer/, adapters/, entrypoints/) – find the boundaries, find the ports.</li>
  <li>Apply the two-minute habit first: check licence and maintenance status (last commit, open issues) – one of this week's study objects carries a no-derivatives licence, and finding it yourself is part of the exercise.</li>
  <li>Shortlist candidates for the platform core – which of L, MM or MM+HX carries your requirements profile R(platform) from A1? – and begin evaluating candidate architectures for the deterministic core and the edges.</li>
  <li>Draw the C4 context and container diagrams of your platform draft; the C4-style diagram is part of the architecture dossier (Deliverable A2, end of week 7).</li>
  <li>Do not start production code before the design-review gate at the end of week 7; exploratory spikes are allowed.</li>
</ul>
<p><em>No deliverable is due this week.</em></p>