Open kubazuch opened 1 month ago
Looks great, I would suggest to either use exactly one repository or to use other services in a service.
It should nicely layer our app: Repository -> Repository manager service -> Service -> Controller
On the other hand it may be overkill for our app, let me know what do you think
Delete review endpoint shouldn't be managed by the product controller. Deleting should be done with the reviewId, user can delete only their review, moderator can delete any review.
PUT
requests should be changed to PATCH
requests.
PUT
requests should be changed toPATCH
requests.
Not all. Some of the request can still be PUT but I want to have both PUT and PATCH for most of the endpoints
Delete review endpoint shouldn't be managed by the product controller. Deleting should be done with the reviewId, user can delete only their review, moderator can delete any review.
I think that the placement of all endpoints needs to be reconsidered. We will discuss that during next meeting.
Read current code and refactor all weak points.
DDD plan
Controller
->Service
->Repository
and ONLY like that.Service
can use otherServices
,Repository
can use otherRepositories
,Service
can use only oneRepository
!PUT
edit endpoint, it should ideally also have aPATCH
edit endpoint, wherePUT
takes whole object, andPATCH
just some of the object fields.API layer
Controller
Controller
can callService
, controller also usesDtos
andMappers
Controller
is the only place in the app that knows about users as in their credentials and authoritiesAuthentication authentication
as parameter andauthentication.getPrincipal()
to get logged inUser
@...Mapping(params = ...)
to separate logic depending on parameterDomain layer
Services
returnModel
objects, there are noDtos
in anyService
Services
Infrastructure layer
Smaller tasks, divided by domain