4. Solution Strategy

Ar42 specifications helper

Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape the system’s architecture. These include

• technology decisions

• decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

• decisions on how to achieve key quality goals

• relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

Motivation

These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.

Form

Keep the explanation of these key decisions short.

Motivate what you have decided and why you decided that way, based upon your problem statement, the quality goals and key constraints. Refer to details in the following sections.

Area	Decision	Motivation (ties to quality goals & constraints)
4.1 System type & decomposition	• “Modular monolith” back-end, but deployed as three Docker services:  1 provider-portal-backend (Spring-Boot runtime, modular hexagonal code)  2 provider-portal-frontend (Vue 3 SPA, served by Vite preview / Nginx)  3 provider-portal-db (MySQL 8) • Runtime layering remains Hexagonal/DDD (Entities ▸ Use-cases ▸ Adapters). Clean architecture inspried and a DDD-inspired module split:  – Entities = RFQ, Quote, Supplier, Event  – Uses cases = use cases + services  – Interface adapters = REST, WebSocket/STOMP, JPA, SMTP, external system clients.	Keeps deployment & ops simple for a student project (T-1, T-6) while isolating business logic so we can extract micro-services later (Quality Goal 3 Evolvability).
4.2 Front-end style	Vue 3 SPA generated by Vite + Pinia store + Vue-Router; pages align 1-to-1 with core use cases (Create RFQ, Compare Quotes…). UI talks only to the REST & WS gateways, never directly to DB or other services.	Leverages team skills (T-2), enables p95 < 1 s interactions (Goal 1 Performance) and keeps FE/BE loosely coupled (API-First).
4.3 Integration strategy	API-First: Every external or internal boundary owns an OpenAPI 3.1 contract; mock servers unlock parallel work. WebSocket/STOMP is the sole push channel for real-time events.	Ensures predictable integration (Goal 4 Interoperability) and zero-lag UX; satisfies constraint T-5 and T-9.
4.4 Quality-attribute tactics	Performance – lean DTOs Security – JWT Token, secrets via Docker env/secret (T-8) Availability – Docker health-checks (/actuator/health, SPA probe); restart: unless-stopped; MySQL volume for crash safety; compose depends_on: condition: service_healthy to guarantee start-order.** Testability – Clean architecture structure enables isolated test and integrated;	Directly addresses quality goals (1–4).
4.5 Tooling & process	• Scrum (2-week) with Sprint with a shift to Kanban (O-1). • Trunk-based Git, GitHub Actions CI: build, test, Docker push, SSH deploy to VPS. GitHub Actions pipeline now builds and pushes two images (backend, frontend) and pulls the official mysql:8.3; compose file is the single source of deployment truth. • Balsamiq for low-fidelity UX (D-0005). • Maven dependency mgmt .	Aligns with constraints and keeps feedback cycles short, underpinning Performance & Evolvability goals.
4.6 Documentation	arc42 master doc (this file) + C4 diagrams for context/container/component/runtime; BPMN for core RFQ flow; UML class diagram for concept model and UML sequence for runtime. All docs live beside code and are versioned; key decisions captured (C-4).	Ensures a single source of truth and passes university assessment while remaining lightweight for the team.

---