Software Architecture Basics

Learning Objectives

• Explain architecture vs lower-level design.
• Design a simple layered architecture.
• Compare monoliths and microservices honestly.
• Identify boundaries around UI, domain, data, and external systems.

Lecture Notes

Software architecture is the high-level structure of a system. It includes major components, communication paths, deployment decisions, data ownership, security boundaries, and technology choices. If class design is about organizing rooms, architecture is about designing the building.

Layered architecture is a common starting point. A simple app may have a UI layer, application/service layer, domain layer, and data layer. The UI handles interaction. Services coordinate use cases. The domain contains important rules. The data layer handles storage. The key design concern is dependency direction: business rules should not depend directly on UI widgets or database details.

Client-server architecture separates user-facing clients from backend services. The client might be a web app or mobile app. The server exposes APIs, validates rules, manages data, and integrates with other systems. API design becomes part of architecture because it defines the contract between client and server.

A monolith is an application deployed as one unit. Monoliths are not automatically bad. For small teams and early products, a well-structured monolith is often simpler, faster, and more reliable than a distributed system. Microservices split capabilities into independently deployable services, which can help large organizations but adds network, data consistency, monitoring, and deployment complexity.

Architecture is about tradeoffs. A design that is perfect for a five-person class project may fail at million-user scale. A design for million-user scale may be absurd for a prototype. Good architects explain context: team size, change rate, risk, budget, performance needs, and operational complexity.

Worked Example: Layered task app architecture

Button click handler -> localStorage -> email provider -> overdue calculation -> HTML rendering -> analytics

UI Layer
- Renders screens and captures user actions

Application Layer
- TaskService, ReminderService, CourseService

Domain Layer
- Task, Course, DueDatePolicy, RecurrenceRule

Infrastructure Layer
- LocalStorageTaskRepository, EmailNotificationSender, AnalyticsClient

Lab: Architecture Sketch

Scenario: Design a course registration system for a college.

Steps

1. Identify users and core use cases.
2. Draw a layered architecture.
3. Define the main API or service operations.
4. Identify external systems such as identity, payment, or email.
5. Write three architectural tradeoffs.

Deliverables

• Architecture diagram
• API/service list
• Tradeoff explanation

Assignment

Create an architecture diagram for your capstone and explain why you chose that structure.

Discussion Prompts

• When is a monolith the better choice?
• What complexity do microservices add?
• Which layer should own business rules?

Week 12 Quiz

Use these as quick checks after the lesson.

Student Notes

Saved in this browser only.