SaFi Bank Space : SaFi What do you want to enhance?

This is a page to collect ideas about what you observe in the code which can be improved.

And this could be one of the input for us to plan the tech tasks(code refactor, fix tech debts etc.) for the up-coming tech transition time (around 6 weeks).

Please don’t hesitate to input your ideas and observations , anything could be helpful

What is it about ?	Detail Description	Related Domain/Codebase	Who find it	Notes
The postings and transaction types are defined by each squad independently, which is hard to maintain	The account squad generated a posting library to resolve this problem. Every squad should integrate the posting library	Thought Machine / posting lib	Account Squad	1.lib is built 2.User 83c4d 3. need to change the code to use lib and need test to cover it first
Usage of temporal workflows is not unified. Some of the problems are not well addressed, e.g. how to log, how to throw exceptions, how to retry, how to deal with failure	The usage of temporal is a critical part of our logic. We should define the best practice and unify the usage ASAP	Temporal	Jevan Wu (Unlicensed)	make guideline & best practice for temporal usage common lib(optional)
Current URLs of our endpoints don’t exactly match the rules of RESTful. Shall we have a guideline of what the URLs should be like in the future?	RESTful URLs	RESTful	Jevan Wu (Unlicensed)	noted in previous tech debts
Code is hard to read/maintain for complex services	The way the code is currently organized makes it difficult to read/maintain. It’s fine for simple services, but gets difficult for complicated services such as the transaction processor manager. We should be using a more domain-driven approach for more complicated services	Code Organization	User 55816	May need to change to code architecture to use more domain driven design. User 55816
Our usage of the generated client libraries for REST APIs increases dependencies between services.	Using the generated client libraries makes increases codependency between services and forces the direction of development from producer to consumer instead of being consumer driven.	REST	User 55816	Considering if we can use consumer driven development as well like consumer driven contract testing
Duplicated code for handling idempotency	Code is replicated all over the place with minor variance. This could have been an AOP advice around the endpoint (and message listener) code.	REST, Messaging	Lyndon (Unlicensed)
Duplicated code for handling authorization	same with the duplicated idempotency issue mentioned above. code to look for: authorizationService.authorizeByCustomerId	REST	Lyndon (Unlicensed)
Start using coroutines in services	We should start to use coroutines in our services for better performance	Kotlin	User 55816