Continuing previous article which I have created a skeleton of a microservice for cash account, now I will enhance the basic features of the application, specifically when creating cash transaction.
This is the service class:
@Service
public class AccountTransactionService {
@Autowired
private AccountTransactionRepository accountTransactionRepository;
public AccountTransaction get(Long id) {
return accountTransactionRepository.getReferenceById(id);
}
public AccountTransaction create(AccountTransaction accountTransaction) {
// TODO: put create transaction logic here
return accountTransactionRepository.save(accountTransaction);
}
}When a transaction created, we will reduce the source of fund account and increase the account destination.
@Transactional
public AccountTransaction create(AccountTransaction accountTransaction) {
Long id = accountTransaction.getId();
if (null != id && accountTransactionRepository.existsById(id))
throw new RuntimeException("AccountTransaction already exists, id: " + id);
Long fromAccountId = accountTransaction.getFromAccount().getId();
CashAccount fromAccount = cashAccountRepository.getReferenceById(fromAccountId);
Long toAccountId = accountTransaction.getFromAccount().getId();
CashAccount toAccount = cashAccountRepository.getReferenceById(toAccountId);
fromAccount.setBalance(fromAccount.getBalance().subtract(accountTransaction.getTransactionAmount()));
toAccount.setBalance(toAccount.getBalance().subtract(accountTransaction.getTransactionAmount()));
return accountTransactionRepository.save(accountTransaction);
}@Transactional added because we want all those sql operation to be committed or rollbacked at the same time.
Our hypothetical business analyst who is a banking expert are not happy with this code because so many things to comment, i.e.:
- There is no available balance check before performing the transaction. The source of fund’s customer account balance might go below negative. If the account is customer saving account, it should never goes negative. If it is current account then it might be allowed, depends on the customer facility. This means we need to group cash accounts based on some type or characteristics of the account. This leads us to create another configuration table, which naturally will be called AccountType entity.
- In banking or generally in accounting transaction, it is not common to use term “to” and “from” account. The correct term are debit and credit. The affect of the transaction amount to the account balance is determined by the nature of the account whether the account is debit account or credit account. CashAccount is a Debit Product because it is sitting on the Bank’s Balance Sheet Debit side. CashAccount is also a Liabilities Product, because from the bank’s point of view every saving account is their liability to the customer. And the loans given by the bank are part of Asset Products. For their customer, of course, it is the way around. Our savings are our asset, and our loans are our liabilities.
- The Transactions that can happen to Accounts is too “free style”. There is no logical grouping based on transaction characteristic, and so on.
Only up to now people realizes that the initial design does not cater distinction of type of accounts, type of customers, and type of transactions. This Entity Model our developer painstakingly created will need to go through another round of redesigning (to be honest it took no more than 30 seconds to generate the diagram, but the whole cycle development is taxing everyone mental aptitude).
For now, lets commit the changes including the UML diagrams into our git repository.
Conclusion
Our simple project is really too simple. At least now people realize different aspects of the real requirement behind “just create a microservice to store and manage customer’s saving account”.
References
- Source code can be found and tagged on donniexyz/med-spring-boot-demo .
