From 350a6f86d943f2cd2c6f7b5188d8adbbb447279e Mon Sep 17 00:00:00 2001 From: Muyao CHEN Date: Thu, 17 Oct 2024 21:56:23 +0200 Subject: [PATCH] doc: add diary for use cases --- README.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/README.md b/README.md index 10299ce..a984e6b 100644 --- a/README.md +++ b/README.md @@ -19,6 +19,11 @@ - [The choice of the front end framework](#the-choice-of-the-front-end-framework) - [2024/10/08](#20241008) - [2024/10/09](#20241009) + - [2024/10/11](#20241011) + - [2024/10/13](#20241013) + - [2024/10/15](#20241015) + - [2024/10/16](#20241016) + - [2024/10/17](#20241017) A tricount like expense-sharing system written in Go @@ -409,3 +414,38 @@ do the calculate and send back a list of money one should pay for another. Finally, I think the business logic is still too simple to be put into a "Domain". For now, the service layer is just enough. + +### 2024/10/17 + +The following basic use cases are to be implemented at the first time. + +- [X] A user signs up +- [X] A user logs in +- [] A user lists their events (pagination) +- [] A user sees the detail of an event (description, members, amount) +- [] A user sees the expenses of an event (total amount, personal expenses, pagination) +- [] A user sees the detail of an expense: (time, amount, payers, recipients) +- [] A user adds an expense +- [] A user updates/changes an expense (may handle some extra access control) +- [] A user deletes an expense (may handle some extra access control) +- [] A user restore a deleted expense +- [] A user can pay the debt to other members +- [X] A user creates an event +- [] A user updates the event info +- [] A user invites another user by sending a mail with a token. +- [] A user joins an event by accepting an invitation +- [] A user quits an event (they cannot actually, but we can make as if they quitted) +- [] A user cannot see other user's information +- [] A user cannot see the events that they didn't participated in. + +With those functionalities, there will be an usable product. And then we can +work on other aspects. For example: + +- introduce an admin to handle users. +- user info updates +- deleting user +- More user related contents +- Event related contents +- ex. Trip journal... + +Stop dreaming... Just do the simple stuff first!