Software Architecture Report Path¶

This page deliberately contains no parallel architecture report: every explanation and piece of evidence lives in the versioned development documentation linked below.

Assignment 1: DDD and microservices¶

Analysis overview ¶

This overview maps the analysis material and explains how the Architecture Drivers, Architecturally Significant Requirements (ASRs), User Journeys, User Stories, BDD scenarios, Domain Model and Architecture Decision Records (ADRs) relate to one another. The page also explains which artifacts are requirements, which are normative, and which source wins if two documents disagree.

Architecture Drivers ¶

This page covers the business purpose, validation targets, primary product flows, quality priorities and delivery constraints that shaped PackyTrace. The central artifact is the Architecture Drivers set: it explains why integrability, privacy, consumer usability and modifiability influenced the design more than scale did for the MVP.

Architecturally Significant Requirements ¶

This page moves from broad priorities to requirements that materially affect the system structure. It presents the ASRs and their Quality Attribute Scenarios (QAS), including the source, stimulus, affected artifact, environment, response and measurable response target for performance, availability and privacy.

User Journeys ¶

This page follows complete product experiences from the perspective of the Anonymous Shopper, Sara and Marco. The User Journey diagrams connect the scan, account, personalization, Fridge, privacy, brand-analytics, Shopping List and comparison flows to their story IDs, exit points and failure paths.

User Stories ¶

This page presents the product backlog as role, need and benefit. The User Stories, grouped into eight epics and prioritized with the MoSCoW backlog, show what the product is intended to deliver while clearly separating priority from implementation status.

Behavior-Driven Development ¶

This page shows how the backlog becomes reviewable acceptance behavior. The BDD scenarios turn each epic into a Feature and each story into Given / When / Then acceptance examples, while planned scenarios remain visibly different from behavior that has implementation evidence.

Domain Model ¶

This is the canonical description of the business domain. It contains the Ubiquitous Language, subdomain classification, bounded contexts, context map, aggregates and domain events that define PackyTrace's terminology, ownership boundaries and privacy wall.

Architecture Decision Records ¶

This page examines the decisions that constrain the architecture and the trade-offs accepted with each one. The ADRs record choices such as brand-as-tenant isolation, microservices, schema-per-service storage, Kafka contracts, Keycloak authentication, service layouts, observability and deployment, including decisions that supersede older ones.

Architecture overview ¶

This overview bridges the domain model and the implemented system. The page acts as an architecture map, directing the reader to decomposition, runtime views, code structure, HTTP contracts, event flows, observability, testing and deployment without duplicating their detailed evidence.

Microservices and patterns ¶

This page shows how bounded contexts became eight independently deployed services and which service owns each kind of data. The page presents the microservice decomposition and the implemented API Gateway, CQRS and Circuit Breaker patterns, together with their responsibilities, evidence and trade-offs.

Component and Connector views ¶

This page presents four runtime perspectives rather than one overloaded system picture. The Component and Connector diagrams show the public edge, synchronous internal collaboration, schema-per-service data isolation, and Kafka facts crossing the privacy wall only after aggregation.

Software structure ¶

This page connects architectural boundaries to directories, packages and dependency rules in the repository. The module views, hexagonal service layouts, composition roots and architecture fitness functions explain where code belongs and how CI prevents forbidden dependencies and generated-artifact drift.

OpenAPI reference ¶

This page provides the rendered HTTP interface of every deployed service. The OpenAPI contracts distinguish public and internal routes, document authentication requirements and make clear both what specification linting proves and what still requires runtime conformance tests.

Key flows ¶

This page follows the actual call order for the main consumer operations. The sequence diagrams cover anonymous scan, personalized scan and add-to-Fridge, including service boundaries, synchronous responses, Kafka publication, timeouts and section-level fallback behavior.

Service communication ¶

This page explains when PackyTrace uses immediate HTTP calls and when it publishes facts asynchronously. The synchronous REST flow, versioned integration-event contracts and environment communication matrix explain how services collaborate without sharing another service's code or database schema.

Assignment 2: microservice patterns¶

Microservice patterns ¶

This section focuses on three patterns inside the broader decomposition page. The implemented API Gateway, CQRS read model and Circuit Breaker are described in terms of the problem each solves, the relevant code and runtime behavior, and the cost or limitation introduced by the pattern.

Event Sourcing ¶

This page explains how Fridge and Shopping List preserve lifecycle facts and rebuild current state. The page explains the event stores, aggregate streams, projections, transactional writes, replay and rebuild tests, integration-event contracts and the event-driven Measurement Pipeline, while keeping private domain events separate from public Kafka messages.

Testing strategy ¶

This page shows how evidence is distributed from fast business-logic checks to the full container journey. The test pyramid, integration tests, end-to-end journey and CI workflow explain what each test layer verifies and where coverage is still incomplete.

Observability ¶

This page reviews the platform's operational visibility and its known gaps. It assesses the Health Check API, Application Metrics, Log Aggregation, Distributed Tracing, Exception Tracking and Audit Logging patterns, then connects their instrumentation to the quality scenarios and service levels.

Observability verification ¶

This page follows the evidence path from a requirement to a metric and finally to a dashboard panel. The QAS verification flows, Prometheus metrics, Grafana dashboard captures and verification procedure show how scan performance, degradation and consent-revocation behavior can be inspected without treating a screenshot as permanent proof.

Deployment overview ¶

This page compares the two application runtime targets and the separate documentation host. The deployment view summarizes the AWS single-server demonstration, the local Kubernetes reference and Cloudflare Pages, explaining the purpose and production limitations of each environment.

AWS application deployment ¶

This page follows the infrastructure and operational path for the public demonstration. The Terraform infrastructure, EC2 and Docker Compose runtime, Caddy public edge, SSM secret flow, GHCR delivery pipeline and Prometheus/Grafana stack show how the eight services are deployed while their internal boundaries remain intact.

Assignment 3: event-driven architecture and service levels¶

Event-driven Measurement Pipeline ¶

This section follows consumer-side facts from Kafka ingestion to privacy-safe brand output. The Kafka topics, event-ID deduplication, windowed counters, minimum-group-size privacy gate and BrandMetricBatchPublished contract explain why raw scans never cross into Brand Analytics.

SLOs and SLIs ¶

This page shows how service-level intentions become calculated measurements. The SLO-1 scan-latency target, SLO-2 scan-availability target, SLI formulas, Prometheus recording rules and error budgets state what is measured, over which window, and which part of the public journey is not yet instrumented.

Kubernetes deployment ¶

This page examines the local orchestration reference and how it differs from a production cluster. The Kustomize base and overlay, Deployments, StatefulSets, health probes, resource requests and limits, security contexts and Horizontal Pod Autoscaler show how PackyTrace maps onto Kubernetes and which production concerns remain outside the demonstration.