Sprint 1: Core System Foundations

Session Timeline

Learning Objectives

• Understand common software architecture patterns
• Learn when to apply different architectural styles
• Design system architecture diagrams for team projects
• Understand what makes a Minimum Viable System (MVS)
• Implement first functional component collaboratively
• Practice agile development workflows during sprint
• Use version control effectively for team development
• Track progress on Kanban boards in real-time

What is Software Architecture?

Why Architecture Matters:

• Guides Development: Team knows how components fit together
• Enables Parallel Work: Team members work on different components simultaneously
• Scalability: Design for growth from the start
• Maintainability: Clear structure makes changes easier
• Communication: Shared understanding across team

Client-Server Architecture

┌─────────────────┐         HTTP/REST         ┌─────────────────┐
│                 │ ◄─────── Request ────────► │                 │
│     CLIENT      │                            │     SERVER      │
│  (Frontend UI)  │ ◄─────── Response ───────► │   (Backend API) │
│                 │                            │                 │
└─────────────────┘                            └────────┬────────┘
                                                        │
                                                        â–¼
                                                 ┌──────────────┐
                                                 │   DATABASE   │
                                                 └──────────────┘
                    

Use When:

• Building web or mobile apps with backend
• Need to separate UI from business logic
• Want multiple clients (web, mobile) using same backend

Client-Server Example: E-Commerce App

// Client: Fetch products from server
async function getProducts() {
  const response = await fetch('http://api.example.com/products');
  const products = await response.json();
  return products;
}

// Server: Product API endpoint
app.get('/products', async (req, res) => {
  const products = await db.query('SELECT * FROM products');
  res.json(products.rows);
});

API-First Architecture

                 ┌─────────────────┐
                 │   API GATEWAY   │
                 └────────┬────────┘
                          │
          ┌───────────────┼───────────────┐
          │               │               │
    ┌─────▼─────┐   ┌────▼────┐   ┌─────▼─────┐
    │   Web     │   │  Mobile │   │  Partner  │
    │   Client  │   │   App   │   │    API    │
    └───────────┘   └─────────┘   └───────────┘
                    

Benefits:

• Multiple frontends can use same API
• Frontend and backend teams work independently
• Clear contract between teams (API specification)
• Easier to test and document

Layered (N-Tier) Architecture

┌─────────────────────────────────────┐
│      Presentation Layer (UI)       │
├─────────────────────────────────────┤
│    Application Layer (Business)    │
├─────────────────────────────────────┤
│    Data Access Layer (Database)    │
├─────────────────────────────────────┤
│         Database                    │
└─────────────────────────────────────┘
                    

Layer Responsibilities:

• Presentation: User interface, input validation
• Business Logic: Application rules, calculations, workflows
• Data Access: Database queries, ORM operations
• Database: Data storage

Microservices Architecture

                    ┌──────────────┐
                    │  API Gateway │
                    └──────┬───────┘
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼──────┐ ┌─────▼─────┐ ┌──────▼──────┐
    │   User      │ │  Product  │ │   Order     │
    │  Service    │ │  Service  │ │   Service   │
    └──────┬──────┘ └─────┬─────┘ └──────┬──────┘
           │               │               │
        ┌──▼──┐        ┌──▼──┐        ┌──▼──┐
        │ DB  │        │ DB  │        │ DB  │
        └─────┘        └─────┘        └─────┘
                    

For Your Projects: Start with monolith (one server). Microservices add complexity.

Data Pipeline Architecture (For ML/Data Projects)

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│   Data   │───►│  Clean/  │───►│   ML     │───►│  Serve   │
│  Ingest  │    │Transform │    │  Model   │    │  Results │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
                    

Model-View-Controller (MVC) Pattern

        ┌─────────────┐
        │    VIEW     │  (UI - displays data)
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │ CONTROLLER  │  (Logic - handles events)
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │    MODEL    │  (Data - business objects)
        └─────────────┘
                    

Separation of Concerns:

• Model: User, Product, Order classes
• View: React components, HTML templates
• Controller: Route handlers, API endpoints

Choosing the Right Architecture for Your Team

What is a Minimum Viable System?

MVS Examples by Project Type

Part B: Building Your First Component

Today's Goal:

• Choose ONE user story from sprint backlog
• Break it into tasks
• Assign tasks to team members
• Start implementation during session
• Use Git branches and collaboration
• Update Kanban board as you progress

Common First Features to Build

Breaking Down a Feature Into Tasks

Technical Tasks:

1. Database: Create users table with schema (name, email, password hash)
2. Backend: Create POST /api/register endpoint
   • Validate input (email format, password strength)
   • Hash password with bcrypt
   • Insert user into database
   • Return success/error response
3. Frontend: Build registration form
   • Input fields (name, email, password, confirm password)
   • Client-side validation
   • Call API on submit
   • Show success or error message
4. Testing: Test registration flow end-to-end

Team Task Assignment Strategy

Git Workflow During Sprint

# 1. At start of feature
git checkout main
git pull origin main
git checkout -b feature/user-registration

# 2. Work on your task, commit frequently
git add src/components/RegisterForm.jsx
git commit -m "feat: add registration form UI"

git add src/api/auth.js
git commit -m "feat: add registration API call"

# 3. Push to remote regularly (backup + visibility)
git push origin feature/user-registration

# 4. When done, create Pull Request
# Team reviews code, suggests changes

# 5. After approval, merge to main
# Delete feature branch after merged

Team Code Review Guidelines

What to Check:

• Functionality: Does it work? Does it meet acceptance criteria?
• Code Quality: Readable? Well-structured? Follows team standards?
• No Bugs: Check for obvious errors, edge cases
• Tests: Are there tests? Do they pass?
• Documentation: Complex code have comments?

Quick Team Check-ins

1. Progress Update: What have you completed?
2. Current Work: What are you working on now?
3. Blockers: Stuck on anything? Need help?

Integrating Team Code

Integration Challenges:

• Merge Conflicts: Two people edited same file
  Solution: Pull from main frequently, communicate about file changes
• API Mismatches: Frontend expects different response than backend sends
  Solution: Agree on API contract first, document it
• Environment Differences: Works on one person's machine, not others
  Solution: Use .env files, Docker, document setup clearly

Testing Your Component

Levels of Testing:

// Simple API test example (Jest + Supertest)
test('POST /api/register creates new user', async () => {
  const response = await request(app)
    .post('/api/register')
    .send({ email: 'test@example.com', password: 'password123' });
  
  expect(response.status).toBe(201);
  expect(response.body).toHaveProperty('userId');
});

Keeping Kanban Board Updated

Best Practices:

• Move card to "In Progress" when you start
• Add comments with updates or blockers
• Move to "Review" when ready for PR
• Move to "Done" only when merged and deployed
• Update at least once per day

Common Sprint 1 Issues & Solutions

Before Next Lecture

1. Complete Sprint 1 Work:
   • Finish your assigned tasks
   • Create pull requests for review
   • Review teammates' code
   • Merge approved PRs
2. Update Documentation:
   • Save architecture diagram to docs/architecture.md
   • Update README if needed
3. Prepare for Review:
   • Test your feature end-to-end
   • Prepare to demo what you built
   • Note any challenges for retrospective
4. Submit to Moodle:
   • Architecture diagram
   • Link to merged PRs
   • Screenshot of working feature