Algo que me chamou a atenção na API é o uso de class
no nome dos arquivos, User.class.ts
, por exemplo.
Não compreendi o uso dessa notação e para ser sincero, acredito que se seja desnecessário, pois não impacta em nada a leitura com a ausência desse class
.
Pontos que podem ser explorados no estudo
Diminuir boilerplate das classes
Notei que as entidades foram criadas para ser somente leitura, com todos os atributos privados.
É possível reescrever com uma quantidade menor de código.
Original
class Transfer {
id
private _senderTransaction
private _receiver
private _cash
constructor(
id: string,
_senderTransaction: Transaction,
_receiver: User,
_cash: number,
) {
this.id = id
this._senderTransaction = _senderTransaction
this._receiver = _receiver
this._cash = _cash
}
public get senderTransaction(): Transaction {
return this._senderTransaction
}
public get receiver(): User {
return this._receiver
}
public get cash(): number {
return this._cash
}
}
Modificado
class Transfer {
id
readonly senderTransaction
readonly receiver
readonly cash
constructor(
id: string,
senderTransaction: Transaction,
receiver: User,
cash: number,
) {
this.id = id
this.senderTransaction = senderTransaction
this.receiver = receiver
this.cash = cash
}
}
Modificado V2
class Transfer {
constructor(
id: string,
readonly senderTransaction: Transaction,
readonly receiver: User,
readonly cash: number,
) {}
}
Documentação
Senti falta de uma documentação da API, para compreender quais ações são possíveis, o que é esperado de entrada e seus respectivos retornos.
Testes
É um ótimo projeto para realizar a implementação de testes, tanto unitários quanto de integração.
Compreensão da regra de negócio
Embora um sistema de saque e transferência pareça simples, há algo que precisa ser observado.
Não é possível deletar ou alterar ações bancárias, isso faz parte do histórico.
As transações deveriam seguir como lançamentos contábeis e caso a pessoa queria desfazer uma transação errada, ela deve realizar outra transação que anule a anterior.