Is your feature request related to a problem? Please describe.
As per #1264 , the current issue service performs both an API request and DTO mapping within the same methods which makes it harder to make individual API calls and work with the returned API objects.
Describe the solution you'd like
Ideally, the issue service should have public methods to perform the API call + DTO mapping while maintaining internal/public methods that perform the pure API calls. So the resulting service may look like the one made for updateIssue where there is a updateGithubIssue for the API call and adjacent updateIssue to perform the DTO mapping from the API call from updateGithubIssue.
This makes the entire service more composable and easier to extend/modify in the future.
Describe alternatives you've considered
Retaining the existing system works too since it currently does not have any major "bugs" that I know of, but having such atomicity would definitely make it easier to debug the system as method calls are now literally comprised of atomic operations that can be more easily inspected and modified without changing large amounts of behavior like in #1264 .
However, this is really up to the team's decision, am more than happy to discuss the nuances in this issue or the subsequent PR :)
Is your feature request related to a problem? Please describe. As per #1264 , the current issue service performs both an API request and DTO mapping within the same methods which makes it harder to make individual API calls and work with the returned API objects.
Describe the solution you'd like Ideally, the issue service should have public methods to perform the API call + DTO mapping while maintaining internal/public methods that perform the pure API calls. So the resulting service may look like the one made for
updateIssuewhere there is aupdateGithubIssuefor the API call and adjacentupdateIssueto perform the DTO mapping from the API call fromupdateGithubIssue.This makes the entire service more composable and easier to extend/modify in the future.
Describe alternatives you've considered Retaining the existing system works too since it currently does not have any major "bugs" that I know of, but having such atomicity would definitely make it easier to debug the system as method calls are now literally comprised of atomic operations that can be more easily inspected and modified without changing large amounts of behavior like in #1264 .
However, this is really up to the team's decision, am more than happy to discuss the nuances in this issue or the subsequent PR :)
Additional context N/A