<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=384306) </details> <!--IssueSummary end--> ## Summary All of the classes are inside `Projects::LfsPointers` module: ```mermaid flowchart TB LfsImportService#execute --> LfsObjectDownloadListService#each_list_item LfsObjectDownloadListService#each_list_item --> LfsDownloadLinkListService#each_link LfsDownloadLinkListService#each_link -->|lfs object link| LfsObjectDownloadListService#each_list_item LfsObjectDownloadListService#each_list_item -->|lfs object link| LfsDownloadService#execute ``` The code inside classes more or less readable but connections between those classes and their responsibility getting into confusion. All we need is to re-struct this part of code. Maybe more horizontal structure like one organiser that calls each action-class sequentially. And do the single time context verification instead of few dublications as it currently works (for ex. `project.lfs_enabled?`) ## Improvements Increase readability & maintainability of the code ## Involved components | Importer | How LFS are imported | | ------ | ------ | | GitHub | Uses `Projects::LfsPointers::LfsObjectDownloadListService`, which was modified by this MR | | BitbucketServer | Uses `Projects::LfsPointers::LfsImportService#execute`, which the downstream code was modified by this MR | | GitlabProject | Imports LFS objects contained in the imported .tar.gz using a different method | | Projects::ImportService | Uses `Projects::LfsPointers::LfsImportService#execute`, which the downstream code was modified by this MR |