doc: add diary for use cases
All checks were successful
Build and test / Build (push) Successful in 2m21s

This commit is contained in:
Muyao CHEN 2024-10-17 21:56:23 +02:00
parent a7a915d825
commit 350a6f86d9

View File

@ -19,6 +19,11 @@
- [The choice of the front end framework](#the-choice-of-the-front-end-framework) - [The choice of the front end framework](#the-choice-of-the-front-end-framework)
- [2024/10/08](#20241008) - [2024/10/08](#20241008)
- [2024/10/09](#20241009) - [2024/10/09](#20241009)
- [2024/10/11](#20241011)
- [2024/10/13](#20241013)
- [2024/10/15](#20241015)
- [2024/10/16](#20241016)
- [2024/10/17](#20241017)
<!--toc:end--> <!--toc:end-->
A tricount like expense-sharing system written in Go 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 Finally, I think the business logic is still too simple to be put into a
"Domain". For now, the service layer is just enough. "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!