THE RULES BEHIND THE SOFTWARE
Kanban
A task-board domain built around ownership, capacity limits and persistent state.
01Backlog
02In progress
03Done
Code-native explanation of the implementation. Illustrative data.
- CONTEXT
- University coursework
- MY ROLE
- Sole developer
- TIMELINE
- 2022
- EVIDENCE
- Source reviewed · illustrative diagrams
AT A GLANCE
The rules behind a three-column board
Three-column boards connect membership, ownership transfer and task assignment to SQLite storage. Capacity limits and task transitions live in the C# domain and service layers. A partial WPF frontend exposes that work through a desktop interface.
My contribution +
I developed this project as university coursework. This case covers my implementation and the engineering decisions behind it.
WHAT THE SYSTEM HANDLES
The interesting parts.
Model a clear task lifecycle
Tasks move from backlog to in progress to done. The domain rejects further advancement from done and prevents editing completed tasks.
Implementation details
- New tasks enter the backlog with board-local IDs.
- Titles, descriptions and due dates are validated by services.
- Column capacity applies to new and advancing tasks.
Make ownership and membership explicit
Boards support joining, leaving, assignment and ownership transfer. Leaving a board unassigns that member’s unfinished work; an owner cannot simply leave without transferring ownership.
Implementation details
- Deleting a board requires its owner.
- Task reassignment is controlled by the existing assignee when present.
- An unassigned task may be advanced by a valid member; do not claim only explicitly assigned users can move every task.
Keep a personal view across shared boards
The backend aggregates in-progress tasks assigned to a user across owned and shared boards, and separates board identity from display name.
Implementation details
Persist the model behind the interface
DTOs and mappers serialize board/task state into SQLite. A JSON response boundary connects the backend to the partial WPF view models.
Implementation details
STRUCTURE & JUDGMENT
How the parts fit.
WPF views + view models
Partial desktop frontend
→ ServiceControllerServiceController
Login checks + JSON responses
→ Board / Column / Task / UserBoard / Column / Task / User
Membership, limits, transitions
→ DTOs + mappersDTOs + mappers
Stored state and reconstruction
→ SQLiteSQLite
Users · boards · columns · tasks
- C#
- .NET 6
- SQLite
- WPF / XAML
- Newtonsoft.Json
- log4net
Treat capacity as a rule of the column
Column rejects additions and incoming tasks when full and refuses a new capacity smaller than its existing task count.
WHY IT MATTERSThe same workload limit follows all callers; it does not depend on whether a UI button is disabled. This is a rationale inferred from the code.
Separate membership from task responsibility
Board handles members and ownership; Task handles assignment/reassignment, while leaving a board removes unfinished assignments.
WHY IT MATTERSA shared board can distinguish access to the board from responsibility for a particular item.
Put a response boundary between presentation and core
ServiceController performs common user/login validation and returns JSON error/value responses. The WPF adapter deserializes those responses into frontend models.
WHY IT MATTERSThe partial frontend and grading/test harness call the same backend behavior. The backend is an in-process library/executable, not a remote API.
Scope, limitations & what I would revisit
- README explicitly says partial frontend. BoardView shows three list boxes and a Back button; no complete drag-and-drop editing UI is supported by these views.
- Archived local coursework code, not production authentication: passwords are stored/read as strings and compared directly; DTO SQL embeds string input rather than parameterizing it.
- Frontend startup inserts sample boards/tasks with fixed 2025 due dates, which are now in the past. Current startup/demo data has not been run or repaired.
- The Email setter recursively assigns itself; the UI is not certified functional end to end.
- Tests are console scenario programs, including resets and printed responses, rather than an asserted xUnit/NUnit suite. No current test pass is claimed.