doc: add diary for use cases
All checks were successful
Build and test / Build (push) Successful in 2m21s
All checks were successful
Build and test / Build (push) Successful in 2m21s
This commit is contained in:
parent
a7a915d825
commit
350a6f86d9
40
README.md
40
README.md
@ -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!
|
||||||
|
Loading…
Reference in New Issue
Block a user