starred/go-backend-clean-architecture
1
0
Fork 0
mirror of https://github.com/amitshekhariitbhu/go-backend-clean-architecture.git synced 2026-04-27 05:25:51 +03:00
Code Issues 19 Projects Releases Packages Wiki Activity

[GH-ISSUE #10] Discussion about use cases #4

New issue
Open
opened 2026-03-01 14:36:45 +03:00 by kerem · 2 comments
kerem commented 2026-03-01 14:36:45 +03:00
Owner
Copy link

Originally created by @vladiulianbogdan on GitHub (Jan 25, 2023).
Original GitHub issue: https://github.com/amitshekhariitbhu/go-backend-clean-architecture/issues/10

Hello! Thank you for this repo, it is really helpful. 🎉

I want to ask you about the responsibilities of use cases and controller. If I understood correctly, the controller should have the responsibility of sanitising the input from the route, calling the use case and then returning the response. The use case is the one that contains the business logic.

However, the login use case, is just a wrapper around UserRepository and the actual business logic happens in the LoginController:

[...]
user, err := lc.LoginUsecase.GetUserByEmail(c, request.Email)
	if err != nil {
		c.JSON(http.StatusNotFound, domain.ErrorResponse{Message: "User not found with the given email"})
		return
	}

	if bcrypt.CompareHashAndPassword([]byte(user.Password), []byte(request.Password)) != nil {
		c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: "Invalid credentials"})
		return
	}

	accessToken, err := lc.LoginUsecase.CreateAccessToken(&user, lc.Env.AccessTokenSecret, lc.Env.AccessTokenExpiryHour)
	if err != nil {
		c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()})
		return
	}

	refreshToken, err := lc.LoginUsecase.CreateRefreshToken(&user, lc.Env.RefreshTokenSecret, lc.Env.RefreshTokenExpiryHour)
	if err != nil {
		c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()})
		return
	}
[...]

Here, the controller decides that first we should fetch the user, then we check if the password is correct and if it is, we generate both an access token and a refresh token. This is the business logic of a login and I feel like it should be in the use case.

Originally created by @vladiulianbogdan on GitHub (Jan 25, 2023). Original GitHub issue: https://github.com/amitshekhariitbhu/go-backend-clean-architecture/issues/10 Hello! Thank you for this repo, it is really helpful. 🎉 I want to ask you about the responsibilities of use cases and controller. If I understood correctly, the controller should have the responsibility of sanitising the input from the route, calling the use case and then returning the response. The use case is the one that contains the business logic. However, the [login use case](https://github.com/amitshekhariitbhu/go-backend-clean-architecture/blob/main/usecase/login_usecase.go), is just a wrapper around `UserRepository` and the actual business logic happens in the `LoginController`: ``` [...] user, err := lc.LoginUsecase.GetUserByEmail(c, request.Email) if err != nil { c.JSON(http.StatusNotFound, domain.ErrorResponse{Message: "User not found with the given email"}) return } if bcrypt.CompareHashAndPassword([]byte(user.Password), []byte(request.Password)) != nil { c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: "Invalid credentials"}) return } accessToken, err := lc.LoginUsecase.CreateAccessToken(&user, lc.Env.AccessTokenSecret, lc.Env.AccessTokenExpiryHour) if err != nil { c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()}) return } refreshToken, err := lc.LoginUsecase.CreateRefreshToken(&user, lc.Env.RefreshTokenSecret, lc.Env.RefreshTokenExpiryHour) if err != nil { c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()}) return } [...] ``` Here, the controller decides that first we should fetch the user, then we check if the password is correct and if it is, we generate both an access token and a refresh token. This is the business logic of a login and I feel like it should be in the use case.
kerem commented 2026-03-01 14:36:46 +03:00
Author
Owner
Copy link

@marcosvidolin commented on GitHub (Aug 29, 2023):

Just bringing up a point for discussion. I've noticed that the use cases have multiple responsibilities, as seen in the case of LoginUsecase. This use case encompasses various functions: GetUserByEmail, CreateAccessToken, CreateRefreshToken...

From my perspective, Login itself should already be a use case.

loginUsecase = usecase.NewLoginUsecase()
loginUsecase.execute()

Whats your thoughts?

<!-- gh-comment-id:1697952928 --> @marcosvidolin commented on GitHub (Aug 29, 2023): Just bringing up a point for discussion. I've noticed that the use cases have multiple responsibilities, as seen in the case of LoginUsecase. This use case encompasses various functions: GetUserByEmail, CreateAccessToken, CreateRefreshToken... From my perspective, Login itself should already be a use case. ```go loginUsecase = usecase.NewLoginUsecase() loginUsecase.execute() ``` Whats your thoughts?
kerem commented 2026-03-01 14:36:46 +03:00
Author
Owner
Copy link

@Redarcher9 commented on GitHub (Sep 9, 2023):

Hello! Thank you for this repo, it is really helpful. 🎉

I want to ask you about the responsibilities of use cases and controller. If I understood correctly, the controller should have the responsibility of sanitising the input from the route, calling the use case and then returning the response. The use case is the one that contains the business logic.

However, the login use case, is just a wrapper around UserRepository and the actual business logic happens in the LoginController:

[...]
user, err := lc.LoginUsecase.GetUserByEmail(c, request.Email)
	if err != nil {
		c.JSON(http.StatusNotFound, domain.ErrorResponse{Message: "User not found with the given email"})
		return
	}

	if bcrypt.CompareHashAndPassword([]byte(user.Password), []byte(request.Password)) != nil {
		c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: "Invalid credentials"})
		return
	}

	accessToken, err := lc.LoginUsecase.CreateAccessToken(&user, lc.Env.AccessTokenSecret, lc.Env.AccessTokenExpiryHour)
	if err != nil {
		c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()})
		return
	}

	refreshToken, err := lc.LoginUsecase.CreateRefreshToken(&user, lc.Env.RefreshTokenSecret, lc.Env.RefreshTokenExpiryHour)
	if err != nil {
		c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()})
		return
	}
[...]

Here, the controller decides that first we should fetch the user, then we check if the password is correct and if it is, we generate both an access token and a refresh token. This is the business logic of a login and I feel like it should be in the use case.

Will it be a good idea to implement all the repository related functions in usecase and use the controller only for sanitising the input from the route, calling the use case and then returning the response?

<!-- gh-comment-id:1712547879 --> @Redarcher9 commented on GitHub (Sep 9, 2023): > Hello! Thank you for this repo, it is really helpful. 🎉 > > I want to ask you about the responsibilities of use cases and controller. If I understood correctly, the controller should have the responsibility of sanitising the input from the route, calling the use case and then returning the response. The use case is the one that contains the business logic. > > However, the [login use case](https://github.com/amitshekhariitbhu/go-backend-clean-architecture/blob/main/usecase/login_usecase.go), is just a wrapper around `UserRepository` and the actual business logic happens in the `LoginController`: > > ``` > [...] > user, err := lc.LoginUsecase.GetUserByEmail(c, request.Email) > if err != nil { > c.JSON(http.StatusNotFound, domain.ErrorResponse{Message: "User not found with the given email"}) > return > } > > if bcrypt.CompareHashAndPassword([]byte(user.Password), []byte(request.Password)) != nil { > c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: "Invalid credentials"}) > return > } > > accessToken, err := lc.LoginUsecase.CreateAccessToken(&user, lc.Env.AccessTokenSecret, lc.Env.AccessTokenExpiryHour) > if err != nil { > c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()}) > return > } > > refreshToken, err := lc.LoginUsecase.CreateRefreshToken(&user, lc.Env.RefreshTokenSecret, lc.Env.RefreshTokenExpiryHour) > if err != nil { > c.JSON(http.StatusInternalServerError, domain.ErrorResponse{Message: err.Error()}) > return > } > [...] > ``` > > Here, the controller decides that first we should fetch the user, then we check if the password is correct and if it is, we generate both an access token and a refresh token. This is the business logic of a login and I feel like it should be in the use case. Will it be a good idea to implement all the repository related functions in usecase and use the controller only for sanitising the input from the route, calling the use case and then returning the response?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
pull-request

Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/go-backend-clean-architecture#4
No description provided.