Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of one usecase into another #37

Open
artem-malko opened this issue Jan 26, 2020 · 4 comments
Open

Usage of one usecase into another #37

artem-malko opened this issue Jan 26, 2020 · 4 comments

Comments

@artem-malko
Copy link

artem-malko commented Jan 26, 2020

First of all, thanks for great articles. It really helps me)

As I understand, it's ok, that usecase layer can be depend on many repositories. We can see it in article_usecse.go But let's imagine, that I have users and sessions. In user we can Create and Delete users. In sessions we can Create and Delete Session. Create and Delete are methods of usecase layer in users and sessions. The problem is in Delete method. If we delete user, we also need to delete sessions. So, it means, that I need to add session usecase Delete to user usecase layer. Is it ok? It can be something like that in main.go

sessionUsecase := NewSessionUsecase(sessionRep)
userUsecase := NewSessionUsecase(userRep, sessionUsecase)

Thank you)

@artem-malko
Copy link
Author

I have one Idea, how to implement it — create one more entity. Something like userSession. It can be depend on user usecase and session usecase. But it means, that user usecase won't have method Delete. And it looks quite strange)

@bxcodec
Copy link
Owner

bxcodec commented May 15, 2020

Hey bro @artem-malko, sorry for the late reply, so busy lately hope you doing good.

If I understand correctly,

  • You have user usecase,
    • Delete and Create
  • You also has session usecase
    • Delete and Create

When Delete user called, session delete also called as well, and that goes to Creation as well? Right?

And you're confusing to import the usecase? Well, IMO, it's okay, because either it was repository or usecase, you still communicate with interface anyway. And they will still independent, you can still do testing without really tight coupled between those two.

But If I were you, I will import the session repository in User usecase, and user repository in Session usecase.

They still have different scope, but the shared the same state which is the repository.

Hopefully, this answers your question

@artem-malko
Copy link
Author

@bxcodec thx for your reply)

I've added high-order entity — manager) For example, I have user manager, which includes user and session services (usecases in your terms). Only manager could start transaction, manager could use services in high-order methods like Delete)

Delete for router = delete User + delete Session. So, I have the delete-method in my manager, which starts transaction and delete user via user service and delete session for user via session service.

So, it looks like: repository (as an interface to DB) —» service (as an interface to usecase in your terms. Could include many repositories) —» manager (as main interface). So, my API can calll only one method of manager to delete any user) And it's much more easy to test it, cause in API tests I need to mock only one manager method (in case of delete testing).

So, what do you think about such architecture?)

@rafi
Copy link

rafi commented Oct 19, 2020

@artem-malko sounds interesting. Can you share an example of structure and snippets?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants