13 trang
2 lượt tải
Lộ Trình Xây Dựng Website Quản Lý Chi Tiêu
4
Lộ trình xây dựng website quản lí chi tiêu bằng công nghệ ReactJS kết hợp với node js
Tác giả:
Danh sách Quiz
Lộ Trình Phát Triển Hệ Thống Quản Lý Chi Tiêu Gia Đình: Phân Tích Kiến Trúc, Thiết Kế và
Thực Thi Chiến Lược trong 300 Giờ
!"#$%&$'()*+,-
&./01%23!#452&6!6)
17$589:$;<=%>#>!
?@A$ABCDCE+#<$F?
G
)$%#93HH&$'IA*
.JKA*L+M)N>O>P62
QRASTAA)*+-#!6JT=BRM<
U++#)93*>1+.$9VWNX2Q19YZ!
6JT++LAM)1[\2)+$+
$%+V.]^^:<D'>&#>!
*9R_`=JRAA)_A$)`$A)=AAAM##6_ULR)/
3+'&.9-+9W3J=A*Ta+M)
$%*+Jbb+A1M1<U*++
#1[1+,-)22 17$5)293
=+A**+-)*+1P;
+*1)1*A1AA<
!"#
=%>#>!
G
)$%9322#2*+
+*)
1cA+$d19:O6We<
$%&%' %()*+
(,- RASTAAJC*
b+A$fUA$M
_gTCFLZh
Ji+$A<j1fg"A11MkTZL
J_A<j1M
.,/#01 TAZAL+
JTZLM)R++AS*1A$
_A<j1VA)
1A*l_A$"C++
201 _gTCFLZh6mTni i+$A<j1Jg"A11M
N
DRfTAAB#A
%3456)7 _=UDT
JD#ToBfZ+1AToBM)
D+1)TAA$A1
Z+1AToBkTAApA
n_DJ+D+1q
TAA$M
,' =+A)$+AS++1A R+AWr$H
'JL)=U)_AA1A
Z+"#M
8/"# mKC)s1Z11I+$)
RToBhjA+ftTT
U#)sAA)g"A11S
$+)ZAApA$
oAA1
)/97: tu+&.
J-"\M
C-+6
WJTI1ASAM)
=%*+$/6
%8$%>1%v*2)eew3
x.[<_A<j1i+$A<j1.+1mTx\JFS
1mTM)Q9W:+V.]^^:<Z+1AToB
938#D#ToB$+e"u#\&.w3$5
mTni )''+95\+.N9:$;<
y
;<=$%&>?@97:
AB/CDEFDBGH
Y*+.!>8\#v#>!r93
O,-'<T%\*.++.#9:$z2
.JASI+M(++.1<
]
;<=,I9*GJAK%E/L0M01
K0MM%/#,/LH
@>!
G
#HW]/<C+5
>)"./#!\Q%2N
+OW9:$;<
1. 4NM#0K1A8,O7PHC
○ Quyền hạn:RW#6#-+'+)"A$1*+$
>vJ1939:$;)v+$H+M)
$19:$;JWf7W+M)\
1J$'{+.6w3)$'OHM<
○ Ý nghĩa:|*++}-N,-)
+$5>9Nr!2+
w3<
~
2. .LN0,A,*59@Q%RE*3S4#THC
○ Quyền hạn:C.+WJ?b#Y+?M):>)
2-1vJD1AU$AM)>$#+93.
&)"A*++2N\>+<
○ Nghiệp vụ:|#/++')H
$/6*v.&+><
•
3. .LN0U0,AE*3S%M#/0,HC
○ Quyền hạn:Y(+$H+$H)"A*++
)"A.1JA$S+#M)6"\+
V<
○ Hạn chế:X"A2+$H>9N>
2931c)#v\Q1v<
€
D_ULR#0•#>!N6/.+1%
\d)+(+*+-7!D$$AIA
<
‚
;;VWO)/97:S:A%/:L0XM0MM
)/H
|..+H%2)1[3*+
&.)93"+R_`=9:{
● B+G{C-C+| YsWi3J=A*Ta+L+M{
C++OW)69:+J$'{L
6)U6e)R6hAAM).9V3!7>&.<
s1[O-+xHJYCA+#M9W193
+$H!2+3<C#LU)UR)RL)-+
1[+$/6/JiAb+IM6"\+$HJ$'{
!LRM<ƒ|#e+\9:\#+&$'
aA!9TI1A<
● B+y{=%U+=/C6RU+TVJR1b+Ib+A1M{
=%>H1u>+H„J_Ag"A1A1M)
1[1u$'9 x##2 JBA_AA11+M
+Ow:JCATAA1L#11M$%*+1$9+
<i2"9V>.A$8931)1[u
*+?TV?#:2•931<…
● B+]{tuBY+=H|HX„J_AC1+gAM{
s! 2%.+*+$H++
HJ6)iA†")hAAM!9:$;-N
<|6#/022TA$AJ9+$AS+M.#6)
17$5#+.+.+*$%>!
1\JFAA#M#*‡!<G^
Y (,-7P(# (%3456
)7AB/;CFEZDBGH
C225‡6+Ww<
Y+.#-+W$522LZh<
Y(# (43[') (#A\E\##N
0L#/M:,H
R 17$51[93227$.RPW]J]ibM*++}
$5<=9V#%NQ{
1. ]M0,MA9*GJHC$)1AA)11I+$E1)A)+A)AA$E<
2. .L0MAB?HC$)A)+IAE$JbXSˆ`1A1M<
3. .LN0U0,MAB?HCU#2
D#S+SD#5`1A1bA1<1AE$)F#E$)j+A$E)
11JAfA$M<
4. ^LL0#MA=HC$)A)*A)A#)1AE$J*AS2
>M)F#E$J*AS2M<B+*{D
6`1Asn‰Rb#)+OW<
GG
5. %#0/,0MAHC$)A)#AJA"A1Af+AM)AE$J#
+$'+M)+<
6. ,M#/MAB/OHCC%<$)+)$A)$A1+)
IAE$)A+#E$)1AE$J9:%M)AA$E1+E$J+
+$H#6f3M<
7. 10#MA9<4WHC$)+E)1E$A)A$E$A)A+#E$)
F#E$<
8. 0,,##0,MA_O `HC$)FAA#J$#)IAA#)+#M)
A"EE$A)+)$A1+<
D5C1+1U$A1+)
W+.%2<Cv+NC1+1++:
$'9 &1[931+1V+ENU$A1<
GG
Y;(# (Ka\4bL
LZh1[9322A+P_gTC)1u$'9 &sCCZJYgC)ZnTC)
Z`C)=gBgCgM5Š<CLZh1[93%W*l
TIAfnALZh<
G
D1g$+8{
● ZnTCfff+{t%6mKCJLA11C+Ak_AFA1C+AM<
● YgCff1+1{B\#$1+$H)w3A#18J‹
1=AŒ<<<qA$=AŒ<<<qA+#h$Œ<<<MJ‹AŒGqŒy^M<
● ZnTCffFA1f{$fj+{Yu#>!<
● YgCffA+1f+#{C6$5•v3+*xJLAA
=M<+v3JLA+M>93%7!
=*1AJ1u$'Y_n`ZU@+ToBM#+*$56i+$A<j1
"u)l9e<
y
YY%()*+,' /20,
R\Q$+AS++1A<#1[*+x]1AA1{
1. 1UCTu$'A+1A1{G•SA<R\+AA11$5
J+1A1E${ff*f+1A1f$M<
2. :CU$r=+AaA+9'*A$<Tu$'+$A++
9:$A+SA+$<
3. c0UCU$r=+AaA+9'F+A$<C+9:$A)
+A#.#A1AA<
1u$'=+A*+9:x\5>
+WJ2WM09:+$+")&#>
!?=A+#A?N6<
G]
F),?%(#AYDDBGH
B93‚T)wT(+$+~^S•^:)-
+#+eW.#93J=AA*A1M<
4:,#C 5/%d?>,*GABGDEYDH
● #CC2-"+9:)=+A)Y†+I2
=*1A<
● %#(#>7C
1. X7.+YA+JYs*fYB*M)2-$A<
G
2. RO\Q9'D++A+JfA)f1AA)f$+AM<
3. 2$+AS++1A<#7.#Z+1A1i+$A<j11AAw<
4. RO9d{g"A11)TAApAJUA$M•_A)CI$RTT)
L"+1Jb+A$M<
5. C2-gTBZAA*+?R+$R+A+?#r!<
4:,#;C201%/,0EK#e#UM0,#/MABG
YEfDH
● #Cs+1 xRT=B"%<
● %#(#>7C
1. 2+11+\*J`1A1)KA1)C1+1<<<M<
2. 2TAA$A11u$'9FA<j1.+G^^^*-
JC1+1M''ue<
G
3. hAA+$AL{_A1A)B+)_AFA1C+A<
4. D•W-P*l*#<
5. C.+D$$AIA"%mKCJD$$AIAM#6
J+AD$$AIAM<
‚
4:,#YC201M0MM)/E%]e97:ABG
fE;DH
● #CLZh++&e<
● %#(#>7C
1. hAAR_`=+C1+1)KA1)RA+A1<
2. tu+{X"WKA)"AWC1+1>
JT+F$AAA1s$$AAAM<
3. t#$%%/:L0X)/A0,,\0HC2+j+*.#w
u>)(*_AZA1).+1+V22.<
G^
4. t#$%LZh_A+1{Tu$'TAApALA+1vf
A+)A+$'<
4:,#FC.,/#01%/,0EB/7e=+:ABG;E
fDH
● #CY+$9:$;+.93V$5-rLZh<
● %#(#>7C
1. C22B#+JT$A*)i*M1u$'CI$RTT<|*+
_A1+1A>D+*A<
G
2. hAAB+f_A1A)9mKC+B+T+A+Osn#
R++A<
3. t#$%=1*+${sH1$9)$1+$H!#<
4. C3LZh{Tu$'"+1AA+1%ŽC+A+
A$A"u_AFA1C+A2.<
G€
4:,#gC.,/#01K101E'[e)/S:
ABGfE;;DH
● #CC%W$5e+<
● %#(#>7C
1. C3R<j1+O_A1<
G‚
[*x/J \>M*
xJ-1>M<
2. t#$%?iTY|?{R+(b#DA2
-.&<
3. hAA%/:L0X)/;A0U#4:Lh#/]aHCsHxH3
+W<$'{L3UG^^)U3RG^^SˆsH6"\
?LRG^^?JUA$\LZh+)b+A$H2M<
ƒ
4. $+F+{Tu$'9b+@*‡w-#
.b+A$J$'{T693)#9379
2>%2M<
G
4:,#iC0M#j.Xek:#l#/ABG;;E;iDH
● #C|*+\93vH<
● %#(#>7C
1. 2`CA1+++&.7UA$J1u$'
mA1M<
2. hA+CA1+LZh8JB+)RAAC1+M<
3. Xu*+-{CuToBhjA+J*+n_D•OM)tTT
JA1A$5!M<
4. C9e{C>h$A"+##\J$'{
1+E$A)A+#E$M+Z+1AToB<
GG
4:,#fC/7j)7e@B@ABG;iEYDDH
● #CRP*H1P*+*+<
● %#(#>7C
1. 2*++#2JCA_A+M{[.1 xg_=)`1AR1A)
LAA*l'9=I<++OT`DB<
Gƒ
2. t\LZhrTIA<
3. o#$A+=A+J•S‚QMA+H*{|e-SˆC>>Sˆ
tA*++SˆR*+1SˆoHL$<
4. T+.T$A#2<
5. X!aA$+AS++1A<#*+>W
.#$%*lG<
G
g4</%WB8W: !"#
A0L00:0H
gB8"#Pm@9+A0U#4:Lh#/H
C+5>WJTA$KAM)\6?L3*+>‹?
*+&.<s1[$'-+JYAA$#L+M
#2*+#<
● 9NLnCC+1$9/JiAUAMNw9:<i9:W1$9
$9 9:!93JRA$+M)9:W1$99:3J=A*+M<
● N#,?C
1. CiAUA+\><
2. Cy$1{=A*+1J1$9•^MRA$+1J1$9ˆ^M<
3. T‡"2y$1A+H#$!<
4. B\#9:36\+9:93-6\<T6+
$HŒDJ•=A*•)•RA$•M<
5. R--.1$9O.+2$1w<
● (#o8CY193+$H#6!%)9
W9:$;<
G…
g;8/"#6)7%=
&$'"u$5.#)**+-1*‡
*{
● #aM/L#/A%>L":16L7HCDO$;1u$'=*1A)9
8#\JoA#M>2C1+1+OKA16Ž
A+6Ksg_gF#E$Œ1A<F#E$+O1AE$Œ
AE1A<$<|6#eOwh=n_Jh1AA=An*jA
_AFAAA1M) 1AW"A+$HN9:*lvh=
>`_B<
‚
● 40M#0#,/#0#/CR9-P93*eJ1M
*l-+.JU#fL+yM<LZhXA#+OTAAXA#J$;+mKCM
93$S+$A+•x.r*29:J<AM)
aA<A93>+<+A8>Ys*<
G
gY,@6)7A#MLl#/H
Tu$'9R<j1)1[\W11‡6{
● 'p[X*qA)0%,#HCC't:)C'@16<YQ
9:$;-$??>*\9:<
● 'p[:<UPA/#%,#HCsH‘8$'<$'{
?’?2~^“v><
● !#"#XrLnC|*+e$5>V*)
UA$1[6$5•93WJ+A$$M#6I$
b+A$%+<|6#+$#*e
.<
y^
i (#)"*qW#,'
C+/]^^:)#*+"#$%+s
oR>Y&!#N#>!8-
‡AJ=+A)D+1AA1SA$#AA)R+A"B+M/
.H1u$'%2+<
$'#P9D+1)TAA$A1)
=+Ap+RhfR=1+Q1>AV9:
#><Re+9-+ W3$%*+
\8)9$#-+e
#2\611‡N9:<
*q:W##,'#*3LA.#,0^/,2HC
● C3LhfnR_JnRA_A++M%(W \#
-<
yG
● Z&$'$JD+*ALM1u$'_AiA)-$'.
++UA$LZh•"#$%<
● C3nAULZhx*+$H%2rJ2
6+(M<
U++#W/9*22,-JCAUAM)H
9V8#2H+)*+$%6Q.
V\93+\<
8<GB%(#A0KLL/#/UL0H
B/ /#
%=
GBABGH (#8
B/
A0L0,UL0MH
<= C-#>
!)HŠ
_+A)R8CA
T
y^ CO
#>!JT_TM
DW
=+)i>
&-+
J=A*L+M
y^ T xx$5
)B+
b+I1
;(# ( C22RT=B
Jg_=M)|HŠ
LZhR+
JTIAM
y• g_=+)
CLZh
KAF
`hf`t
JbfTAM
y• D+1+
$2
Y>,*G C2-=+A)
Y_A+)RhfR=
B
y^ D9:=A
1”1JnAS
+$1AM
2=UD+
T1)B+
TAA$
JbA<j1M
G^ =*1AW$5
zJG^^^
A+$1M
F201 D+$AL
JmKC)_ULR)
_A1AZ11I+$M
y• LZh|e
-f|e
*+-
R+AC1+
qU$AR_`=
]^ LZh
C>fTuftW
+$H
R+A"B+{
_A
Z#A1q=A*
L+
]• TAA"u
'&
.
g.,/#01 X7.+$%)
_+)L
ZA1
y^ Y+$|e
-f|e
=1*+$
R++A1q
C3R<j1
]^ =1*+$9
)Ux
b+
+$Hq
$+
Jb+f@M
]^ Y+$-
W
w
iW@ Ce_AS
AJT+A<+M
y^ C*+&
:
qR*+
g"+fh+
bAA1qC
`h
y^ R&e"\
g"AfZ=b)`h
93
f/7 `qhA+
CA1)b"U
]^ U*$v
H)w
>8
2*++)
T$A)o#$A+
=A+
y^ YW1P
„
s9B%t9B FDD• (Lưu ý: Đã bao
gồm thời gian dự
phòng và tự học)
Lưu ý: Mặc dù yêu cầu đặt ra là 300 giờ, bảng phân bổ trên mở rộng lên 400 giờ để
bao gồm cả thời gian tự nghiên cứu công nghệ mới (learning curve) và xử lý các vấn
đề phát sinh không lường trước (buEer). Tuy nhiên, các đầu mục cốt lõi (Core
Features) hoàn toàn có thể hoàn thành trong 300 giờ nếu tuân thủ nghiêm ngặt kế
hoạch.
9[#,=1_
1. @A$ABCDCE+#<$F
2. U$ZA1+bADAAL{=*1ATAI
Z+1AToB$=+A<•*#YA+A–AF1•C+I$1=gAA
•DA$)#-+GG^)y^y€)1{ffA$<+f+I$1S
$SAAAf*$SSA1+SaASAASS
$*1AS1ASIS+1A1S$S$+AS•^‚•Ayƒ]]^]A
3. s+I+Z$g"AATA11FKA*L+=AA+A
Z+jA)#-+GG^)y^y€)1{ff$A<+f*AEA$f+IS+S
S$SA"AASS1A11FSIA*S+S$AA+AS+jAS
G
4. Kh1_+ASU1A$LA11R++J_ULRM‹DAqg"A1S
b+A)#-+GG^)y^y€)
1{ffIII<F+A<+fA1+A1f#*A+11#f+AS*1A$SA11S
++
5. =A1$hAA++Fb#g"A1ACA`1Dg_i
TSj)#-+GG^)y^y€)
1{ffj<+f+$1f€hTT`gƒfhm_Z_•yyy~<$F
6. TI1ASLT+ASLA)#-+GG^)y^y€)
1{ff1<A<+f1ff1I1Af$~•ƒ^y]~]]
7. s+I+hAA_ULRg"A11<j1L+SZA<+)#
-+GG^)y^y€)1{ffIII<A<+f*+f+IS+S
AAS*SSSA"A11j1S+
8. L+UA$TI1A—1=A*Ta+bAA•*#D
D+X•DA$)#-+GG^)y^y€)
1{ffA$<+f˜…]f+S*A$S1I1A1S$A*S
1a+SFAASƒ~ƒ•A…‚€ƒƒ
9. s+I+L+Abb+A1{ƒZ+A11A1@+RL+A
•iATA)#-+GG^)y^y€)
1{ffIII<A1A<+f+fA1+AfA1faS
AAf+ASaSF+A1<1
10. T#1A=A1ZAF+_AZ#A1SYAA1F+YAA1)#
-+GG^)y^y€)1{ffIII<AA1F+AA1<+f1#1AS
$A1f1#1AS$A1SASF+SAS#A1f
11. =A1$*1A1AF+*$AAIL+AS
*++#A1#<+)#-+GG^)y^y€)
1{ff*++#A1#<+f*+f$*S1ASF+S*$ASASIS
+Af
12. =#A"A1AASg#SA+1$A"ASYAA<+)
#-+GG^)y^y€)1{ffIII<AA<+fAA1fA"A1AS
ASA$
13. BA=+A]+1<S=gR+#)#-+GG^)
y^y€)1{ff$A<+f+EA$A+E]…~^FfAS$+ASS]S
+1S…G
14. TA`=+A{i+$A<j1qZ+1AToB•bTU+)#-+
GG^)y^y€)1{ffIII<F1<+f*1fA1+A1f*+f1ASS
$+AS$AA+ASA+ASSA1S+$+
15. D+1•TAApA)#-+GG^)y^y€)
1{ff1AApA<+f$+1f€f+AS+1f+1f
16. s+I+U$bST_AR_`=LIi+$A<j1)g"A11$
Z+1AToB{TAS*#STAY$AS=gR+#)#-+G
G^)y^y€)1{ff$A<+f+*$+f+IS+S*$SSFS1SAS$S
SIS+$Aj1SA"A11S$S+1A1S1AS*#S1AS$AS]y]A
17. T+ZRB*#F+_A‹CA1AG^n+1R+A
hL•sAi++)#-+GG^)y^y€)
1{ffA++<+f1S+SSSS*#SF+SAS
A1ASG^S++1S+ASS
18. Y$A+CA_A+KS`A1#+FT11A")#-+
GG^)y^y€)
1{ffIII<111A"<<fAfAfF+1$A1fAAA$A1f
1$#$A1fAA+I
19. L++1Af1AAA"A1A1++STnA†+I)
#-+GG^)y^y€)
1{ff1+A†+I<+fA1+1f…‚~…yyf+S+S1AS1AAS
A"A1A1S+SS+
20. _AmT=AA+AF+_ASCAL#1=1*+$1SDA1=A)
#-+GG^)y^y€)1{ffA1$A<+f*+fAj1S$AS
F+SASAS#1S$1*+$1
21. JZ=bMgtZgiTgC_LRXg_LZZBhRLChniS_A1AYA)#-+
GG^)y^y€)
1{ffIII<A1AA<Af*+f]ƒGy~…•‚…EgtZgiTgEC_LRXg
_ELZZBhRLChni
Bấm Tải xuống để xem toàn bộ.
Preview text:
Lộ Trình Phát Triển Hệ Thống Quản Lý Chi Tiêu Gia Đình: Phân Tích Kiến Trúc, Thiết Kế và Thực Thi Chiến Lược trong 300 Giờ
1. Tổng Quan Điều Hành và Phạm Vi Dự Án
Việc phát triển một hệ thống quản lý tài chính cá nhân và gia đình không chỉ đơn thuần là việc xây dựng một ứng dụng ghi chép thu chi, mà là một bài toán kỹ thuật phức tạp đòi hỏi sự kết hợp nhuần nhuyễn giữa kiến thức về công nghệ phần mềm, quản lý cơ sở dữ liệu và tâm lý học hành vi người dùng. Dựa trên tài liệu yêu cầu "Yeu cau de tai LTMT_copy.pdf" 1, dự án này được định vị là một ứng dụng web hiện đại (Web Application), tuân thủ nghiêm ngặt các tiêu chuẩn công nghiệp về kiến trúc Client-Server, bảo mật và quy trình phát triển phần mềm (SDLC).
Báo cáo này, được biên soạn dưới góc nhìn của một Kiến trúc sư Giải pháp Phần mềm (Solution Architect), sẽ cung cấp một lộ trình chi tiết, toàn diện để hoàn thành dự án trong giới hạn 300 giờ làm việc. Mục tiêu không chỉ là đáp ứng các yêu cầu cơ bản như CRUD (Create, Read, Update, Delete) hay phân quyền RBAC, mà còn tích hợp các logic nghiệp vụ phức tạp như thuật toán tối ưu hóa nợ (Debt Simplification), dự báo tài chính (Financial Forecasting) và quản lý ngân sách động. Bản báo cáo này sẽ đi sâu vào phân tích kỹ thuật, thiết kế cơ sở dữ liệu, chiến lược triển khai Docker và các biện pháp bảo mật, đảm bảo sản phẩm cuối cùng là một hệ thống robust, scalable và secure.
1.1 Mục Tiêu Dự Án và Ràng Buộc Kỹ Thuật
Dựa trên tài liệu yêu cầu 1, dự án được thiết kế để giải quyết bài toán quản lý tài chgggggggggggggggggggggggggggggính trong bối cảnh hộ gia đình, nơi việc chia sẻ chi phí và theo dõi ngân sách chung thường gặp nhiều khó khăn.
Hạng Mục | Yêu Cầu Cụ Thể | Chiến Lược Thực Thi |
Kiến Trúc | Client-Server (Tách biệt Frontend/Backend) | RESTful API (Node.js/Express) + SPA (React.js) |
Frontend | Single Page Application (SPA), Component-based | React.js với Vite, quản lý state bằng Redux Toolkit |
Backend | RESTful API trả về JSON | Node.js (Express) tuân thủ mô hình MVC/Service Layer |
Cơ Sở Dữ Liệu | RDBMS (MySQL/PostgreSQL), Migrations, Seeders | PostgreSQL + Sequelize ORM (cho Migrations & Seeding) |
Triển Khai | Docker, docker-compose | Container hóa từng dịch vụ (App, DB, Reverse Proxy) |
Bảo Mật | JWT, Hash Password, Chống SQL Injection/XSS | Bcrypt, Helmet, Express-validator, Parameterized Queries |
Logic Nghiệp Vụ | Xử lý logic phức tạp (không chỉ nhập xuất) | Thuật toán chia tiền nhóm (Splitwise-like), Dự báo dòng tiền |
Việc lựa chọn công nghệ dựa trên sự phổ biến, hiệu năng và khả năng hỗ trợ cộng đồng mạnh mẽ. React.js và Node.js tạo thành một stack JavaScript đồng nhất (full-stack JS), giúp tối ưu hóa thời gian phát triển trong giới hạn 300 giờ. PostgreSQL được chọn thay vì MySQL do khả năng xử lý các truy vấn phức tạp và hỗ trợ kiểu dữ liệu JSON tốt hơn, phục vụ cho việc lưu trữ các cấu hình linh hoạt của người dùng.2
2. Phân Tích Yêu Cầu và Mô Hình Hóa Nghiệp Vụ (Giai Đoạn 1: 0 - 40 Giờ)
Gibai đoạn đầu tiên và quan trọng nhất là chuyển đổi các yêu cầu trừu tượng thành các đặc tả kỹ thuật cụ thể. Sự thất bại trong giai đoạn này thường dẫn đến việc phải làm lại (re-work) tốn kém trong các giai đoạn sau.3
2.1 Phân Tích Vai Trò Người Dùng (RBAC - Role Based Access Control)
Yêu cầu 1 quy định hệ thống phải có tối thiểu 3 vai trò. Trong ngữ cảnh quản lý chi tiêu gia đình, việc ánh xạ các vai trò này cần phản ánh cấu trúc thực tế của một hộ gia đình hoặc một nhóm người dùng chung.
- System Admin (Quản Trị Hệ Thống):
- Quyền hạn: Có quyền truy cập toàn cục vào hệ thống, xem dashboard thống kê tổng quan (số lượng người dùng, tổng giao dịch toàn hệ thống), quản lý danh sách người dùng (khóa/mở khóa tài khoản), cấu hình các tham số hệ thống (ví dụ: loại tiền tệ hỗ trợ, danh mục mặc định).
- Ý nghĩa: Đảm bảo tính toàn vẹn và vận hành của hệ thống kỹ thuật, không can thiệp vào dữ liệu tài chính riêng tư của các gia đình trừ khi cần thiết cho việc hỗ trợ.4
- Family Manager (Trưởng Nhóm/Chủ Hộ - Tương ứng Staff):
- Quyền hạn: Tạo nhóm gia đình ("Family Group"), mời thành viên tham gia, thiết lập ngân sách tổng (Master Budget), phê duyệt các khoản chi vượt hạn mức, xem báo cáo chi tiết của tất cả thành viên trong gia đình.
- Nghiệp vụ: Đây là vai trò trung tâm trong logic nghiệp vụ, chịu trách nhiệm quản lý dòng tiền chung và phân bổ hạn mức cho các thành viên.5
- Family Member (Thành Viên - Tương ứng Customer):
- Quyền hạn: Ghi chép giao dịch cá nhân và giao dịch chung, xem báo cáo cá nhân, xem trạng thái ngân sách chung (read-only), đề xuất các khoản chi lớn.
- Hạn chế: Không thể xem chi tiết các giao dịch riêng tư của thành viên khác nếu không được chia sẻ, không thể thay đổi cấu trúc ngân sách tổng.6
Mô hình RBAC này không chỉ thỏa mãn yêu cầu của đề tài mà còn tạo ra sự phân cấp rõ ràng, cho phép triển khai các logic bảo mật ở tầng Middleware một cách hiệu quả.7
2.2 Xác Định Logic Nghiệp Vụ Phức Tạp (Complex Business Logic)
Để đạt điểm tối đa và tạo ra giá trị thực tế, hệ thống sẽ tích hợp ba mô đun logic phức tạp, vượt xa các thao tác CRUD thông thường:
- Logic 1: Thuật Toán Đơn Giản Hóa Nợ (Debt Simplification Algorithm):
Trong một gia đình hoặc nhóm, khi nhiều người chi trả cho nhau (ví dụ: A trả tiền điện, B trả tiền ăn, C trả tiền Internet), mạng lưới nợ nần trở nên phức tạp. Hệ thống sẽ cài đặt một thuật toán đồ thị (Graph Theory) để tối ưu hóa số lượng giao dịch cần thiết để thanh toán nợ. Thay vì A trả B, B trả C, C trả A, thuật toán sẽ tính toán dòng tiền ròng (Net Flow) và đề xuất các giao dịch tối thiểu (ví dụ: chỉ cần A trả C).8 Đây là một tính năng cao cấp thường thấy trong các ứng dụng fintech hàng đầu như Splitwise. - Logic 2: Dự Báo Dòng Tiền và Cảnh Báo Sớm (Cash Flow Forecasting):
Dựa trên lịch sử chi tiêu và các khoản chi định kỳ (Recurring Expenses), hệ thống sẽ sử dụng phương pháp hồi quy tuyến tính đơn giản (Linear Regression) hoặc phân tích chuỗi thời gian (Time Series Analysis) để dự báo số dư vào cuối tháng. Nếu xu hướng chi tiêu hiện tại đe dọa vượt ngân sách, hệ thống sẽ gửi cảnh báo "Sớm" thay vì chờ đến khi đã vượt ngân sách.9 - Logic 3: Xử Lý Giao Dịch Định Kỳ (Recurring Transaction Engine):
Hệ thống cần một cơ chế để tự động tạo ra các bản ghi giao dịch cho các khoản chi cố định (tiền nhà, Netflix, Internet) mà không cần người dùng nhập liệu thủ công. Điều này đòi hỏi việc thiết kế một Scheduler (như node-cron) chạy nền, kiểm tra cơ sở dữ liệu hàng ngày và kích hoạt logic tạo bản ghi dựa trên tần suất (frequency) và ngày bắt đầu.10
3. Kiến Trúc Hệ Thống và Thiết Kế Cơ Sở Dữ Liệu (Giai Đoạn 2: 41 - 90 Giờ)
Thiết kế hệ thống vững chắc là nền tảng cho việc phát triển nhanh chóng và ít lỗi. Giai đoạn này tập trung vào việc mô hình hóa dữ liệu và thiết kế API.
3.1 Thiết Kế Sơ Đồ Thực Thể Liên Kết (ERD - Entity Relationship Diagram)
Cơ sở dữ liệu sẽ được thiết kế ở dạng Chuẩn hóa 3 (3NF) để đảm bảo tính toàn vẹn dữ liệu. Dưới đây là các thực thể chính và mối quan hệ của chúng:
- Users (Người Dùng): id, username, password_hash, email, role, created_at.
- Families (Gia Đình): id, name, owner_id (FK -> Users).
- FamilyMembers (Thành Viên Gia Đình): Bảng trung gian giải quyết mối quan hệ Many-to-Many giữa Users và Families. user_id, family_id, joined_at, status (active/pending).
- Wallets (Ví Tiền): id, name, balance, currency, user_id (nullable - nếu là ví riêng), family_id (nullable - nếu là ví chung). Logic kiểm tra ràng buộc: Một ví phải thuộc về User HOẶC Family, không thể cả hai hoặc không có ai.11
- Categories (Danh Mục): id, name, type (expense/income), parent_id (đệ quy cho danh mục con), icon.
- Transactions (Giao Dịch): Thực thể trung tâm. id, amount, date, description, wallet_id, category_id, user_id (người thực hiện), related_transaction_id (cho các giao dịch chuyển tiền/trả nợ).
- Budgets (Ngân Sách): id, amount_limit, start_date, end_date, category_id, family_id.
- RecurringPatterns (Mẫu Định Kỳ): id, frequency (daily, weekly, monthly), next_run_date, amount, description.
Mối quan hệ giữa Transactions và Budgets là mối quan hệ tính toán, không phải khóa ngoại trực tiếp. Tổng amount của các Transactions trong khoảng thời gian và danh mục tương ứng sẽ được so sánh với amount_limit của Budgets.11
3.2 Thiết Kế API RESTful
API sẽ được thiết kế theo chuẩn REST, sử dụng các phương thức HTTP (GET, POST, PUT, DELETE) một cách ngữ nghĩa. Tài liệu API sẽ được tự động hóa bằng Swagger/OpenAPI.1
Một số Endpoint quan trọng:
- POST /api/auth/login: Xác thực và trả về JWT (Access Token + Refresh Token).
- GET /api/transactions: Lấy danh sách giao dịch, hỗ trợ query params để lọc (?startDate=...&endDate=...&categoryId=...) và phân trang (?page=1&limit=20).
- POST /api/families/:id/join: Gửi yêu cầu tham gia gia đình.
- GET /api/reports/monthly: Trả về dữ liệu đã tổng hợp cho biểu đồ (Aggregate Data). Việc tính toán tổng hợp (Aggregation) nên được thực hiện ở tầng Database (sử dụng GROUP BY trong SQL) thay vì tải toàn bộ dữ liệu về Node.js để xử lý, nhằm tối ưu hiệu năng.2
3.3 Chiến Lược Triển Khai Docker
Cấu trúc docker-compose.yml sẽ bao gồm 3 services chính:
- db: Sử dụng image postgres:15-alpine. Cấu hình volume để persist dữ liệu (postgres_data:/var/lib/postgresql/data).
- api: Build từ Dockerfile trong thư mục backend. Sử dụng nodemon trong môi trường dev để hot-reload.
- web: Build từ Dockerfile trong thư mục frontend. Trong môi trường dev, container này chạy Vite server.
Việc sử dụng Docker đảm bảo môi trường phát triển đồng nhất giữa các thành viên trong nhóm (nếu có) và mô phỏng môi trường production chính xác, đáp ứng yêu cầu "Deployment" của đề tài.13
4. Lộ Trình Thực Thi Chi Tiết (300 Giờ)
Lộ trình được chia thành 7 Sprint, mỗi Sprint kéo dài khoảng 40-50 giờ, tập trung vào việc chuyển giao các tính năng có thể chạy được (Deliverables).
Sprint 1: Khởi Tạo và Cấu Hình Môi Trường (Giờ 0 - 30)
- Mục tiêu: Thiết lập xong môi trường phát triển, Docker, Git flow và kết nối Database.
- Chi tiết công việc:
- Khởi tạo Git repo (GitHub/GitLab), thiết lập nhánh main và dev.1
- Cài đặt cấu trúc thư mục Monorepo (/client, /server, /docker).
- Viết docker-compose.yml để khởi chạy Postgres và Node.js server rỗng.
- Cài đặt các thư viện lõi: Express, Sequelize (Backend); React, TailwindCSS, Axios (Frontend).
- Thiết lập ESLint và Prettier để đảm bảo "Coding Convention" ngay từ đầu.
Sprint 2: Backend Core - Auth & Database Migrations (Giờ 31 - 70)
- Mục tiêu: Hoàn thiện sơ đồ CSDL và hệ thống xác thực.
- Chi tiết công việc:
- Viết migration scripts cho tất cả các bảng (Users, Wallets, Transactions...).
- Viết Seeders sử dụng thư viện faker.js để tạo 1000 bản ghi giả lập (Transactions) phục vụ kiểm thử hiệu năng và phân trang.1
- Implement module Auth: Register, Login, Refresh Token.
- Mã hóa mật khẩu bằng bcrypt.
- Tạo Middleware xác thực JWT (authMiddleware) và phân quyền (roleMiddleware).7
Sprint 3: Backend Business Logic - CRUD & Nghiệp Vụ (Giờ 71 - 120)
- Mục tiêu: API hoàn chỉnh cho các chức năng chính.
- Chi tiết công việc:
- Implement CRUD cho Transactions, Wallets, Categories.
- Xử lý logic: Khi xóa Wallet, kiểm tra xem có Transactions liên quan không (Soft delete vs Hard delete).
- Xây dựng Complex Logic 1 (Recurring Engine): Viết cron job chạy mỗi nửa đêm, quét bảng RecurringPatterns, tạo transaction mới nếu đến hạn.10
- Xây dựng API Reports: Sử dụng Sequelize Aggregations để tính tổng thu/chi theo tháng, theo danh mục.
Sprint 4: Frontend Core - Giao Diện & Tích Hợp (Giờ 121 - 170)
- Mục tiêu: Giao diện người dùng hoạt động được với dữ liệu thật từ API.
- Chi tiết công việc:
- Thiết kế Layout chung (Sidebar, Navbar) sử dụng TailwindCSS. Đảm bảo Responsive trên Mobile.1
- Implement trang Login/Register, lưu JWT vào LocalStorage hoặc HttpOnly Cookie.
- Xây dựng màn hình Dashboard: Hiển thị số dư, danh sách giao dịch gần đây.
- Tích hợp API: Sử dụng axios và interceptors để tự động đính kèm Token vào header và xử lý Refresh Token khi hết hạn.16
Sprint 5: Frontend Advanced - Biểu Đồ & Logic Phức Tạp (Giờ 171 - 220)
- Mục tiêu: Trực quan hóa dữ liệu và tính năng nâng cao.
- Chi tiết công việc:
- Tích hợp Chart.js hoặc Recharts.17 Vẽ biểu đồ tròn (cơ cấu chi tiêu) và biểu đồ cột (thu nhập vs chi tiêu).
- Xây dựng màn hình "Ngân Sách Gia Đình": Cho phép Family Manager thiết lập hạn mức.
- Implement Complex Logic 2 (Debt Simplification UI): Hiển thị đồ thị nợ trong nhóm. Ví dụ: A nợ B 100k, B nợ C 100k -> Hệ thống hiển thị đề xuất "A trả C 100k" (Backend cung cấp API tính toán, Frontend hiển thị kết quả).8
- Validation form: Sử dụng thư viện Formik và Yup để bắt lỗi nhập liệu ngay tại Frontend (ví dụ: Số tiền không được âm, ngày không được ở tương lai nếu là chi tiêu thực tế).1
Sprint 6: Testing, Fix Bug & Optimization (Giờ 221 - 260)
- Mục tiêu: Đảm bảo chất lượng và độ ổn định.
- Chi tiết công việc:
- Viết Unit Test cho các hàm tính toán logic phức tạp ở Backend (sử dụng Jest).
- Integration Test cho các API quan trọng (Login, Create Transaction).
- Kiểm thử bảo mật: Thử nghiệm SQL Injection (đảm bảo ORM đã chặn), XSS (escape dữ liệu đầu ra).
- Tối ưu hiệu năng: Thêm Indexing cho các cột hay truy vấn (ví dụ: transaction_date, category_id) trong PostgreSQL.11
Sprint 7: Hoàn Thiện, Tài Liệu & Đóng Gói (Giờ 261 - 300)
- Mục tiêu: Chuẩn bị sản phẩm để bàn giao và bảo vệ.
- Chi tiết công việc:
- Viết báo cáo thuyết minh (Technical Report): Vẽ lại sơ đồ ERD, Use Case, Architecture bằng công cụ như Draw.io hoặc StarUML.18
- Xuất tài liệu API từ Swagger.
- Quay Video Demo (5-7 phút) theo kịch bản: Đăng nhập -> Thêm chi tiêu -> Xem báo cáo -> Cảnh báo ngân sách -> Quản trị Admin.
- Soạn Slide thuyết trình.
- Kiểm tra lần cuối file docker-compose.yml để đảm bảo giảng viên có thể chạy dự án bằng 1 câu lệnh.1
5. Đi Sâu Vào Các Giải Pháp Kỹ Thuật (Technical Deep Dive)
5.1 Giải Thuật Tối Ưu Hóa Nợ (Debt Simplification)
Trong ngữ cảnh quản lý chi tiêu nhóm (Shared Wallet), vấn đề "Ai nợ ai bao nhiêu?" là bài toán phức tạp. Hệ thống sẽ áp dụng thuật toán tham lam (Greedy Algorithm) để giải quyết bài toán này.
- Nguyên lý: Tính toán số dư ròng (Net Balance) của mỗi người. Người có số dư dương là người cần được trả (Creditor), người có số dư âm là người nợ (Debtor).
- Quy trình:
- Tính Net Balance cho tất cả thành viên.
- Tách thành 2 danh sách: Debtors (số dư < 0) và Creditors (số dư > 0).
- Sắp xếp cả 2 danh sách theo giá trị tuyệt đối giảm dần.
- Lấy người nợ nhiều nhất trả cho người được nhận nhiều nhất. Số tiền giao dịch = Min(|Debit|, |Credit|).
- Cập nhật lại số dư và lặp lại cho đến khi danh sách rỗng.
- Kết quả: Giảm thiểu tối đa số lượng giao dịch chuyển tiền cần thực hiện, tối ưu hóa trải nghiệm người dùng.19
5.2 Bảo Mật Dữ Liệu Tài Chính
Vì ứng dụng xử lý dữ liệu tài chính nhạy cảm, các biện pháp bảo mật sau là bắt buộc:
- Data Isolation (Cô lập dữ liệu): Mặc dù sử dụng chung một Database, nhưng mọi câu truy vấn (Query) liên quan đến Transactions hoặc Wallets đều phải kèm theo điều kiện WHERE family_id = user.family_id hoặc user_id = current_user.id. Điều này ngăn chặn lỗi IDOR (Insecure Direct Object References), nơi một user có thể xem giao dịch của người khác bằng cách đổi ID trên URL.7
- Sensitive Data Protection: Các thông tin như mật khẩu phải được băm (hash) bằng thuật toán mạnh (Bcrypt/Argon2). API Key hoặc Secret Key (dùng cho JWT) không được hard-code trong mã nguồn mà phải nạp từ biến môi trường (.env), và file .env phải được thêm vào .gitignore để tránh lộ lọt trên GitHub.1
5.3 Trực Quan Hóa Dữ Liệu (Data Visualization)
Sử dụng thư viện Chart.js, hệ thống sẽ cung cấp các góc nhìn sâu sắc về tài chính:
- Biểu đồ xu hướng (Line Chart): Trục X là thời gian, Trục Y là số tiền. Giúp người dùng nhận diện "đỉnh" chi tiêu bất thường.
- Biểu đồ phân bố (Doughnut Chart): Hiển thị tỷ trọng các danh mục. Ví dụ: "Ăn uống" chiếm 40% tổng chi tiêu.
- Kỹ thuật xử lý: Để đảm bảo hiệu năng khi dữ liệu lên tới hàng nghìn bản ghi, Backend sẽ trả về dữ liệu đã được nhóm (grouped data) thay vì trả về raw data để Frontend tự tính toán. Điều này giảm tải cho trình duyệt và giảm băng thông mạng.20
6. Kết Luận và Hướng Phát Triển
Trong vòng 300 giờ làm việc, lộ trình này đảm bảo việc xây dựng hoàn chỉnh một Hệ thống Quản lý Chi tiêu Gia đình không chỉ đáp ứng đầy đủ các yêu cầu học thuật khắt khe (Docker, Microservices-ready architecture, Complex Logic) mà còn mang lại giá trị sử dụng thực tế cao.
Việc áp dụng các quy trình chuẩn công nghiệp như Migrations, Seeders, Dockerization và CI/CD simulation giúp sinh viên làm quen với môi trường làm việc chuyên nghiệp. Các tính năng nâng cao như thuật toán đơn giản hóa nợ và dự báo tài chính là điểm nhấn quan trọng, thể hiện tư duy thuật toán và khả năng giải quyết vấn đề sâu sắc của người phát triển.
Hướng phát triển tương lai (Future Work):
- Tích hợp AI/OCR (Optical Character Recognition) để tự động quét hóa đơn giấy và nhập liệu.21
- Phát triển ứng dụng di động (Mobile App) sử dụng React Native, tận dụng lại hoàn toàn Backend API đã xây dựng.
- Tích hợp Open Banking API để đồng bộ giao dịch trực tiếp từ ngân hàng (nếu điều kiện pháp lý cho phép).
Báo cáo này đóng vai trò như một bản thiết kế kỹ thuật (Technical Blueprint), định hướng mọi quyết định trong quá trình phát triển, đảm bảo dự án về đích đúng hạn với chất lượng cao nhất.
Bảng Phân Bổ Thời Gian Chi Tiết (Time Allocation Table)
Giai Đoạn | Hoạt Động Chính | Thời Gian (Giờ) | Kết Quả Bàn Giao (Deliverables) |
1. Phân Tích | Thu thập yêu cầu, định nghĩa Role, Chọn Tech Stack | 20 | Tài liệu đặc tả yêu cầu (SRS) |
Mô hình hóa Domain, Nghiên cứu thuật toán (Debt Algo) | 20 | Sơ đồ luồng dữ liệu, Logic Flowcharts | |
2. Thiết Kế | Thiết kế CSDL (ERD), Định nghĩa API Contract (Swagger) | 25 | ERD hoàn chỉnh, Tài liệu API |
Wireframing UI/UX (Figma/Sketch) | 25 | Mockups giao diện chi tiết | |
3. Môi Trường | Thiết lập Docker, Git Repo, CI/CD Linting | 20 | Môi trường Dev sẵn sàng (One-command setup) |
Viết DB Migration Scripts, Logic Seeding (Faker.js) | 10 | Database có dữ liệu mẫu (1000 records) | |
4. Backend | Module Auth (JWT, RBAC, Reset Password) | 25 | API Đăng nhập/Đăng ký bảo mật |
Core Transaction & Budget CRUD | 30 | API Thêm/Sửa/Xóa giao dịch | |
Complex Logic: Recurring Payments & Debt Algorithm | 35 | Service xử lý nghiệp vụ phức tạp | |
5. Frontend | Khởi tạo dự án, Routing, Auth Pages | 20 | Giao diện Đăng nhập/Đăng ký |
Dashboard Components & Tích hợp Chart.js | 30 | Dashboard tương tác, Biểu đồ động | |
Form quản lý giao dịch & Validation (Formik/Yup) | 30 | Giao diện nhập liệu có kiểm tra lỗi | |
6. Đánh Bóng | Tính năng Real-time (Socket.io) & Cảnh báo | 20 | Thông báo tức thời |
Export/Import Features & Tinh chỉnh UI | 20 | Chức năng xuất Excel/PDF, UI mượt mà | |
7. Hoàn Thiện | Unit & Integration Testing, Fix Bug | 30 | Bản build ổn định, không lỗi nghiêm trọng |
Viết báo cáo, Slide, Quay Video Demo | 20 | Gói sản phẩm nộp cuối kỳ | |
TỔNG CỘNG | 400* | (Lưu ý: Đã bao gồm thời gian dự phòng và tự học) |
Lưu ý: Mặc dù yêu cầu đặt ra là 300 giờ, bảng phân bổ trên mở rộng lên 400 giờ để bao gồm cả thời gian tự nghiên cứu công nghệ mới (learning curve) và xử lý các vấn đề phát sinh không lường trước (buffer). Tuy nhiên, các đầu mục cốt lõi (Core Features) hoàn toàn có thể hoàn thành trong 300 giờ nếu tuân thủ nghiêm ngặt kế hoạch.
Nguồn trích dẫn
- Yeu cau de tai LTMT_copy.pdf
- Building a Personal Finance Management App: Database Setup with PostgreSQL and Docker. | by George Zefkilis | Towards Data Engineering | Medium, truy cập vào tháng 1 10, 2026, https://medium.com/towards-data-engineering/building-a-personal-finance-management-app-database-setup-with-postgresql-and-docker-5075e283303e
- How to Plan and Execute a Successful Web Application Development Project, truy cập vào tháng 1 10, 2026, https://dev.to/albert_ed/how-to-plan-and-execute-a-successful-web-application-development-project-1kkg
- What Is Role-Based Access Control (RBAC)? Meaning & Examples - Fortinet, truy cập vào tháng 1 10, 2026, https://www.fortinet.com/resources/cyberglossary/role-based-access-control
- Design and Implementation of a Family Expense Tracker Using MERN Stack - ijrpr, truy cập vào tháng 1 10, 2026, https://ijrpr.com/uploads/V6ISSUE8/IJRPR52224.pdf
- Splitwise - App Store - Apple, truy cập vào tháng 1 10, 2026, https://apps.apple.com/us/app/splitwise/id458023433
- How to Implement RBAC in an Express.js Application - Permit.io, truy cập vào tháng 1 10, 2026, https://www.permit.io/blog/how-to-implement-rbac-in-an-expressjs-application
- Algorithm Behind Splitwise's Debt Simplification Feature | by Mithun Mohan K | Medium, truy cập vào tháng 1 10, 2026, https://medium.com/@mithunmk93/algorithm-behind-splitwises-debt-simplification-feature-8ac485e97688
- How to Automate Financial Forecasting: 8 Processes You Can Automate | NetSuite, truy cập vào tháng 1 10, 2026, https://www.netsuite.com/portal/resource/articles/financial-management/automate-financial-forecasting.shtml
- System Design Pattern for Recurring Payments - GeeksforGeeks, truy cập vào tháng 1 10, 2026, https://www.geeksforgeeks.org/system-design/system-design-pattern-for-recurring-payments/
- Designing a database schema for a budget tracker with Automigrate - bogoyavlensky.com, truy cập vào tháng 1 10, 2026, https://bogoyavlensky.com/blog/db-schema-for-budget-tracker-with-automigrate/
- Daily expense tracker - Entity-relationship diagram example - Gleek.io, truy cập vào tháng 1 10, 2026, https://www.gleek.io/templates/expense-tracker-erd
- Learn Docker in 3 hours. - DEV Community, truy cập vào tháng 1 10, 2026, https://dev.to/morning_redemption_3940af/learn-docker-in-3-hours-91p
- Setting Up Docker: Node.js & PostgreSQL | FullStack Blog, truy cập vào tháng 1 10, 2026, https://www.fullstack.com/labs/resources/blog/set-up-docker-development-environment-that-matches-production
- Migrations | Sequelize, truy cập vào tháng 1 10, 2026, https://sequelize.org/docs/v6/other-topics/migrations/
- How to Build a Full-Stack React CRUD App with Node.js, Express and PostgreSQL: Step-by-Step Guide - DEV Community, truy cập vào tháng 1 10, 2026, https://dev.to/corbado/how-to-build-a-full-stack-react-crud-app-with-nodejs-express-and-postgresql-step-by-step-guide-323e
- Struggling to Pick a Charting Library for React? These 10 Options Cover It All | HackerNoon, truy cập vào tháng 1 10, 2026, https://hackernoon.com/struggling-to-pick-a-charting-library-for-react-these-10-options-cover-it-all
- Guide to Technical Report Writing - University of Sussex, truy cập vào tháng 1 10, 2026, https://www.sussex.ac.uk/ei/internal/forstudents/engineeringdesign/studyguides/techreportwriting
- Algorithm to share/settle expenses among a group - Stack Overflow, truy cập vào tháng 1 10, 2026, https://stackoverflow.com/questions/974922/algorithm-to-share-settle-expenses-among-a-group
- ReactJS Development for Real-Time Analytics Dashboards - Makers Den, truy cập vào tháng 1 10, 2026, https://makersden.io/blog/reactjs-dev-for-real-time-analytics-dashboards
- (PDF) EXPENSE TRACKER APPLICATION - ResearchGate, truy cập vào tháng 1 10, 2026, https://www.researchgate.net/publication/381249579_EXPENSE_TRACKER_APPLICATION
