Typeorm Transactions for Clean architecture

[stable nymph]

HI I'm using clean architecture in my project, The issue is I have no idea how can I do the transactions, inside clean architecture, all the examples are showing the default method to do transactions,

In here I want to create my transaction block in use-case level.

these are my repositories.

Thank you

[raw vault]

What documentation are you following that says what you are doing is "Clean Architecture"? You are basically killing a big advantage Nest offers with the project structure you have. Namely modularity. You see, when you build a Nest module as intended, it entails all the "ring levels of architecture" and Nest takes care to put those pieces of the ring together for you to make the final "onion" and all of its rings (as in Onion Architecture, which is a later version of Clean Architecture). You have completely dissected all the rings into their own locations in the project and now you have absolutely no way to reuse a module.

I wrote an article about how to design a Nest project for beginners. I think you should read it. Then you'll probably be able to answer your own question once you understand the modularization technique that Nest smartly offers. https://dev.to/smolinari/nestjs-and-project-structure-what-to-do-1223

Actually, you don't really ask a question. But, I bet making decisions in the end will be easier, when you understand Nest's modularization technique.

[grim gust]

You can utilize the unit of work pattern.

[raw vault]

Rereading your post (it was early with little coffee in my brain) and Donny's reply, this might also be of interest.
https://github.com/odavid/typeorm-transactional-cls-hooked

Your project structure still can be much better too. 😄

I'm also assuming you are using TypeORM too of course. 🙂

[stable nymph]

https://medium.com/@jonathan.pretre91/clean-architecture-with-nestjs-e089cef65045

I referred this article to refactor my nestjs project, is this refactoring unnecessary?

[raw vault]

@stable nymph - Yes. Unless you have some serious reason for doing that refactor, it's far from best practice with Nest. Those three "packages" as the author notes, Domain, Infrastructure and Usecase are usually split in Nest by having a module called "common" or "core" for infrastructure and then all other modules hold both domains and usecases to build a feature. Usecases are called services in Nest. The "domain" is the module. So, in his example, you'd have a "common" folder and a "todo" folder. In the "todo" folder, you'd have controllers, services, interfaces, guards, etc. folders. A mini-onion. Nest puts your modules together to form the big onion.

For a small "todo" application, that might seem strange, but if you have an application with a lot of features, each feature will be its own module and so finding "domain code" and understanding what the application will do is fairly easy. I mean, imagine you have an issue with config in that setup. Where do you go? Domain or Infrastructure? With a proper Nest setup, you'd go to "common/config" and all code will be there in the one (sub-)module.

Or imagine, you'd like to reuse his todo "feature" in some other application aside from a number of other features that application might have. It would be impossible.

His guidance completely breaks Nest's modularisation facility basically denying code reusability for anyone following his advice.

[stable nymph]

Thanks a lot Scott for guiding me, as I am new to Nest and appreciative of his help.

Initially, I followed the above-mentioned article and implemented clean architecture for my NestJS project. However, I now realize that the approach I took may compromise the modular structure of my project. After going through the suggestions made by Scott and the links shared by Donny, I am confused about whether to rebuild my project with a recommended folder structure or modify the current implementation to include transactions.

Based on your previous advice, I was wondering if you could suggest whether it would be better to start over with a new folder structure or continue with the current implementation. Additionally, if you think I should continue with the current implementation, could you suggest any alternative ways to implement transactions?