Kanban
A kanban task-management backend with clean architecture, from storage to REST API.
Role
Backend developer — freelance
Stack
Go, PostgreSQL, REST, Docker
Language
Go
Repository
Link pending
Problem
Team task tracking needs a small, dedicated system: tasks moving through workflow states, ownership, ordering within columns, and an API that other tools can integrate with — without adopting an oversized project-management platform.
Solution
A task-management system modeled around boards, columns, and cards, exposing a REST API built in Go. Structured to keep business logic isolated from transport and persistence.
My contribution
Modeled the domain (board → column → card), designed the database schema, implemented the REST API, and structured the code so domain rules live independently of HTTP and SQL.
Architecture
Layered design: an HTTP layer translates requests into domain operations; domain logic enforces transition rules (e.g. cards move between columns by explicit actions); persistence implements repository interfaces so the storage engine can be swapped without touching business rules.
HTTP / REST handlers
│ validate · translate
▼
Domain operations ── rules: board → column → card transitions
│ repository interfaces
▼
PostgreSQL (Docker)Overview
Kanban is a backend-first task-management system. The core object model is boards containing ordered columns, each containing ordered cards. Cards carry metadata such as assignee and timestamps; columns define the allowed workflow.
Requirements
The system needed to support:
- Creating and archiving boards, columns, and cards.
- Moving cards within and across columns with explicit transitions.
- Querying board state in a single read for UI rendering.
- A REST API that is versionable and easy to document.
Implementation notes
Handlers parse and validate input, then delegate to domain operations. All persistence goes through repository interfaces, which made it straightforward to develop against PostgreSQL in Docker locally.
Technical Decisions
Workflow moves are modeled as first-class operations (MoveCard) rather than raw updates, so invalid transitions are impossible through the API. Ordering is maintained with an explicit position field updated transactionally, keeping list reads trivial and index-friendly.
Results
A clean, documented API surface and a codebase where domain rules can evolve without changes to transport or storage layers.
The hard part
Keeping card ordering inside columns consistent under concurrent updates, while keeping reads simple and fast.
A decision worth noting
Encoded workflow transitions as explicit operations instead of allowing arbitrary state edits on cards — the API rejects invalid moves, which keeps the board state always meaningful.
Outcome
A working backend demonstrating domain modeling, API design, and layered architecture in Go.
Next project
CI/CD Automation