Init: Move design.md, README.md

This commit is contained in:
Lukáš Trkan
2025-09-18 12:31:46 +02:00
parent c7a0898b7d
commit 71b9fa7b5f
2 changed files with 183 additions and 0 deletions

43
README.md Normal file
View File

@@ -0,0 +1,43 @@
# Lab 6: Design Document for Course Project
| Lab 6: | Design Document for Course Project |
| ----------- | ---------------------------------- |
| Subject: | DAT515 Cloud Computing |
| Deadline: | **September 19, 2025 23:59** |
| Grading: | No Grade |
| Submission: | Group |
## Table of Contents
- [Table of Contents](#table-of-contents)
- [1. Design Document (design.md)](#1-design-document-designmd)
The design document is the first deliverable for your project.
We separated this out as a separate deliverable, with its own deadline, to ensure that you have a clear plan before you start coding.
This part only needs a cursory review by the teaching staff to ensure it is sufficiently comprehensive, while still realistic.
The teaching staff will assign you to a project mentor who will provide guidance and support throughout the development process.
## 1. Design Document (design.md)
You are required to prepare a design document for your application.
The design doc should be brief, well-organized and easy to understand.
The design doc should be prepared in markdown format and named `design.md` and submitted in the project group's repository.
Remember that you can use [mermaid diagrams](https://github.com/mermaid-js/mermaid#readme) in markdown files.
The design doc **should include** the following sections:
- **Overview**: A brief description of the application and its purpose.
- **Architecture**: The high-level architecture of the application, including components, interactions, and data flow.
- **Technologies**: The cloud computing technologies or services used in the application.
- **Deployment**: The deployment strategy for the application, including any infrastructure requirements.
The design document should be updated throughout the development process and reflect the final implementation of your project.
Optional sections may include:
- Security: The security measures implemented in the application to protect data and resources.
- Scalability: The scalability considerations for the application, including load balancing and auto-scaling.
- Monitoring: The monitoring and logging strategy for the application to track performance and detect issues.
- Disaster Recovery: The disaster recovery plan for the application to ensure business continuity in case of failures.
- Cost Analysis: The cost analysis of running the application on the cloud, including pricing models and cost-saving strategies.
- References: Any external sources or references used in the design document.

140
design.md
View File

@@ -1 +1,141 @@
# Design Document
> Keep this document brief (24 pages), clear, and up-to-date throughout the project.
> You may use Mermaid diagrams for architecture visuals.
| Field | Value (fill in) |
| -------------- |----------------------------------------|
| Project Name | Personal Finance Tracker |
| Team Members | Lukáš Trkan, Dejan Ribarovski |
| Repository URL | https://github.com/dat515-2025/Group-8 |
| Version | v0.1 (update as you iterate) |
| Last Updated | YYYY-MM-DD |
## How to use this template
- Replace all placeholders with your project-specific content.
- Keep explanations concise; link to code or docs when helpful.
- Update this document as the design evolves to match the final implementation.
---
## 1. Overview
Briefly describe the application and its purpose.
- Problem statement: What problem are you solving?
- Keeping track of all personal finances across multiple bank accounts, cash is not easy. We want to simplify it.
- Target users / personas: Who benefits from this?
- We aim to help people to keep better track of their finance flows, so people can plan bigger expenses or find ways to save money.
- Primary objectives: 35 bullet points.
- Pass th
- Non-goals: What is explicitly out of scope?
- Key features: Short bullet list of core functionality.
## 2. Architecture
High-level architecture, main components, interactions, and data flow. Include a system diagram.
### 2.1 System diagram
```mermaid
flowchart LR
client[Client/UI] --> api[API Gateway / Web Server]
api --> svc1[Service A]
api --> svc2[Service B]
svc1 --> db[(Database)]
svc2 --> cache[(Cache)]
svc2 --> ext[(External API)]
```
- Components and responsibilities: What does each box do?
- Data flow: How does data move between components?
- State management: Where is state stored (DB, cache, object store)?
- External dependencies: APIs, third-party services, webhooks.
### 2.2 Data model (if applicable)
- Core entities and relationships (ER sketch or brief description).
- Example records or schemas (link to files or include concise snippets).
### 2.3 APIs (REST/gRPC/GraphQL)
- Interface style and rationale.
- Link to OpenAPI/Proto files, or list a few key endpoints/RPCs.
## 3. Technologies
List the cloud services, libraries, and tools you will use and why.
| Technology / Service | Role / Where Used | Why chosen (brief) | Alternatives considered |
| -------------------- | ----------------- | ------------------ | ----------------------- |
| | | | |
Notes:
- Languages & frameworks (e.g., Go, Node, Python; Gin, Fiber, Echo).
- Cloud provider and managed services (compute, DB, storage, messaging).
- CI/CD, IaC, containerization.
## 4. Deployment
Describe the deployment strategy and infrastructure requirements.
- Environments: dev / staging / prod (if applicable).
- Runtime platform: Docker, Compose, Kubernetes, serverless, PaaS.
- Infrastructure diagram (optional):
```mermaid
flowchart TB
subgraph Cloud
lb[Load Balancer]
asg[Service / Deployment]
db[(Managed DB)]
bucket[(Object Storage)]
end
user((User)) --> lb --> asg --> db
asg --> bucket
```
- Configuration & secrets: Env vars, secret manager, .env files (never commit secrets).
- Build & release: How artifacts are built; link to CI/CD if used.
- Deployment steps: Summarize here; full, reproducible steps must be in report.md.
- Scaling strategy: Horizontal/vertical scaling, autoscaling triggers.
---
## Optional Sections
Include the sections below as applicable to your project.
### Security
- Authn/Authz model; data protection; TLS/HTTPS; secrets handling; dependency scanning.
### Scalability
- Expected load; performance targets; bottlenecks; caching; rate limits.
### Monitoring & Logging
- Health checks; logs; metrics (e.g., Prometheus); dashboards; alerting.
### Disaster Recovery
- Backups; restore procedures; RPO/RTO targets; failure scenarios.
### Cost Analysis
- Main cost drivers; pricing model; cost-saving measures; budget estimate.
### References
- Links to papers, docs, blog posts, prior art, and any external resources.
---
## Change Log
- v0.1 Initial draft
- v0.2 Architecture updated to match implementation
- v1.0 Final version reflecting delivered system