mmintel/gridpilot.gg
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
d689df0270011be996362b7634e085dbdc4c7d84
gridpilot.gg/plans/api-usecase-presenter-migration.md
Marc Mintel 9bd2e630e6 refactor
2025-12-21 22:35:38 +01:00

31 KiB
Raw Blame History

API Use Case and Presenter Migration Todo List (Per File)

This todo list is structured per domain module and per file. It is intentionally free of code snippets and focuses only on the structural and behavioral changes required.

Global cross-cutting tasks

  • Ensure every migrated use case in the core returns a Result type and uses an output port to present its business result model.
  • Ensure all presenters live in the API layer, receive business result models from use cases via an output port, and store internal response models for the API.
  • Ensure all services in the API layer delegate mapping and response model construction to presenters and do not perform DTO or response model mapping themselves.
  • Ensure repositories and use cases are injected via dependency injection tokens only, never by direct class references.
  • Ensure presenters are never injected into services via dependency injection; presenters should be imported directly where needed and bound as output ports in modules.
  • Ensure use cases never perform serialization or DTO mapping; use cases operate on domain objects and result models only.
  • After each module migration, run type checking, linting, and targeted tests for that module.
  • After all modules are migrated, run full type checking, linting, and the entire test suite.

Analytics domain module

Directory: apps/api/src/domain/analytics

Controllers

  • File: apps/api/src/domain/analytics/AnalyticsController.ts

    • Review all controller methods and update them to consume response models returned from the analytics service rather than constructing or interpreting DTOs manually.
    • Ensure controller method signatures and return types reflect the new response model naming and structure introduced by presenters.

  • File: apps/api/src/domain/analytics/AnalyticsController.test.ts

    • Update tests to assert that controller methods receive response models from the service and do not depend on internal mapping logic inside the service.
    • Adjust expectations to align with response model terminology instead of any previous view model terminology.

Services

  • File: apps/api/src/domain/analytics/AnalyticsService.ts
    • Identify each method that calls a core analytics use case and ensure it passes the use case result through the appropriate presenter via the output port.
    • Remove any mapping or DTO-building logic from the service methods; move all such responsibilities into dedicated analytics presenters.
    • Ensure each service method returns only the presenter’s response model, not any core domain objects or intermediate data.
    • Verify that all injected dependencies are repositories and use cases injected via tokens, with no presenters injected via dependency injection.

Module and providers

  • File: apps/api/src/domain/analytics/AnalyticsModule.ts

    • Ensure the module declares analytics presenters as providers and binds them as implementations of the generic output port for the relevant use cases.
    • Ensure that services and controllers are wired to use analytics use cases via tokens, not via direct class references.

  • File: apps/api/src/domain/analytics/AnalyticsModule.test.ts

    • Update module-level tests to reflect the new provider wiring, especially the binding of presenters as output ports for use cases.

  • File: apps/api/src/domain/analytics/AnalyticsProviders.ts

    • Ensure all analytics repositories and use cases are exposed via clear token constants and that these tokens are used consistently in service constructors.
    • Add or adjust any tokens required for use case output port injection, without introducing presenter tokens for services.

DTOs

  • Files: apps/api/src/domain/analytics/dtos/GetAnalyticsMetricsOutputDTO.ts, GetDashboardDataOutputDTO.ts, RecordEngagementInputDTO.ts, RecordEngagementOutputDTO.ts, RecordPageViewInputDTO.ts, RecordPageViewOutputDTO.ts
    • Verify that all analytics DTOs represent API-level input or response models only and are not used directly inside core use cases.
    • Ensure naming reflects response model terminology where applicable and is consistent with presenters.

Presenters

  • Files: apps/api/src/domain/analytics/presenters/GetAnalyticsMetricsPresenter.ts, GetDashboardDataPresenter.ts, RecordEngagementPresenter.ts, RecordPageViewPresenter.ts

    • For each presenter, ensure it implements the use case output port contract for the corresponding analytics result model.
    • Ensure each presenter maintains internal response model state that is constructed from the core result model.
    • Ensure each presenter exposes a getter that returns the response model used by controllers or services.
    • Move any analytics-specific mapping and transformation from services into these presenters.
    • Align terminology within presenters to use response model rather than view model.

  • Files: apps/api/src/domain/analytics/presenters/GetAnalyticsMetricsPresenter.test.ts, GetDashboardDataPresenter.test.ts, RecordEngagementPresenter.test.ts, RecordPageViewPresenter.test.ts

    • Update tests to validate that each presenter receives a core result model, transforms it correctly, and exposes the correct response model.
    • Ensure tests no longer assume mapping occurs in services; all mapping assertions should target presenter behavior.

Auth domain module

Directory: apps/api/src/domain/auth

Controllers

  • File: apps/api/src/domain/auth/AuthController.ts

    • Review all controller methods and ensure they consume response models returned from the auth service, not raw domain objects or DTOs assembled by the controller.
    • Align controller return types with the response models produced by auth presenters.

  • File: apps/api/src/domain/auth/AuthController.test.ts

    • Update tests so they verify the controller’s interaction with the auth service in terms of response models and error handling consistent with use case Results.

Services

  • File: apps/api/src/domain/auth/AuthService.ts
    • For signup, login, and logout operations, ensure the service only coordinates input, calls the corresponding core use cases, and retrieves response models from auth presenters.
    • Remove all mapping logic in the service that translates between core user or session representations and API DTOs; move this logic into dedicated presenters.
    • Ensure use cases are injected via tokens and that repositories and ports also use token-based injection.
    • Ensure presenters are not injected into the service via dependency injection and are instead treated as part of the output port wiring and imported where necessary.
    • Ensure each public service method returns a response model based on presenter state, not core domain entities.

Module and providers

  • File: apps/api/src/domain/auth/AuthModule.ts

    • Ensure the module declares auth presenters as providers and wires them as implementations of the use case output port for login, signup, and logout use cases.
    • Confirm that the auth service and controller depend on use cases and ports via the defined tokens.

  • File: apps/api/src/domain/auth/AuthModule.test.ts

    • Update module tests to reflect the new wiring of auth presenters as output ports and the absence of presenter injection into services.

  • File: apps/api/src/domain/auth/AuthProviders.ts

    • Verify that all tokens for auth repositories, services, and use cases are defined and consistently used.
    • Add or adjust tokens required for output port injection, ensuring presenters themselves are not injected into services.

DTOs

  • File: apps/api/src/domain/auth/dtos/AuthDto.ts
    • Ensure DTOs in this file represent API-level input and response models only and are not referenced by core use cases.
    • Align DTO naming with response model terminology where applicable.

Presenters

  • Files: apps/api/src/domain/auth/presenters/AuthSessionPresenter.ts, CommandResultPresenter.ts

    • Ensure each presenter implements the generic use case output port contract for the relevant auth result model.
    • Ensure each presenter maintains internal response model state derived from the core result model.
    • Ensure a getter method is available to expose the response model to controllers and services.
    • Move all auth-related mapping logic from the auth service into these presenters.
    • Normalize terminology within presenters to use response model instead of view model.

  • File: apps/api/src/domain/auth/presenters/AuthSessionPresenter.test.ts

    • Update tests so they validate that the auth session presenter receives core result models from auth use cases and correctly transforms them into auth response models.

Dashboard domain module

Directory: apps/api/src/domain/dashboard

Controllers

  • File: apps/api/src/domain/dashboard/DashboardController.ts

    • Ensure controller methods depend on dashboard service methods that return response models, not core objects or partial mappings.
    • Align method return types and expectations with the dashboard response models built by presenters.

  • File: apps/api/src/domain/dashboard/DashboardController.test.ts

    • Update tests to assert that the controller interacts with the service in terms of response models, not internal mapping behavior.

Services

  • File: apps/api/src/domain/dashboard/DashboardService.ts
    • Identify all dashboard service methods that construct or manipulate DTOs directly and move this logic into dashboard presenters.
    • Ensure each service method calls the appropriate dashboard use case, allows it to drive presenters through output ports, and returns a response model obtained from presenters.
    • Confirm that dashboard use cases and repositories are injected via tokens, with no presenters injected via dependency injection.

Module and providers

  • File: apps/api/src/domain/dashboard/DashboardModule.ts

    • Ensure the module binds dashboard presenters as output port implementations for the relevant use cases.
    • Ensure dashboard services depend on use cases via tokens only.

  • File: apps/api/src/domain/dashboard/DashboardModule.test.ts

    • Adjust tests to confirm correct provider wiring of presenters as output ports.

  • File: apps/api/src/domain/dashboard/DashboardProviders.ts

    • Review token definitions for repositories, services, and use cases; ensure all are used consistently in constructor injection.
    • Add or adjust any tokens needed for output port wiring.

DTOs

  • Files: apps/api/src/domain/dashboard/dtos/DashboardDriverSummaryDTO.ts, DashboardFeedItemSummaryDTO.ts, DashboardRaceSummaryDTO.ts
    • Verify that these DTOs are used only as API-level response models from presenters or services and not within core use cases.
    • Align naming and fields with the response models produced by dashboard presenters.

Presenters

  • (Any dashboard presenters, when added or identified in the codebase)
    • Ensure they implement the use case output port contract, maintain internal response model state, and expose response model getters.
    • Move all dashboard mapping and DTO-building logic into these presenters.

Driver domain module

Directory: apps/api/src/domain/driver

Controllers

  • File: apps/api/src/domain/driver/DriverController.ts

    • Ensure controller methods depend on driver service methods that return response models, not domain entities or partial DTOs.
    • Align method signatures and return types with driver response models provided by presenters.

  • File: apps/api/src/domain/driver/DriverController.test.ts

    • Update tests so they verify controller interactions with the driver service via response models and error handling consistent with use case Results.

Services

  • File: apps/api/src/domain/driver/DriverService.ts
    • Identify all mapping logic from driver domain objects to DTOs in the service and move that logic into driver presenters.
    • Ensure each service method calls the relevant driver use case, lets the use case present results through presenters, and returns response models obtained from presenters.
    • Confirm that repositories and use cases are injected via tokens, not via direct class references.
    • Ensure no presenter is injected into the driver service via dependency injection.

Module and providers

  • File: apps/api/src/domain/driver/DriverModule.ts

    • Ensure driver presenters are registered as providers and are bound as output port implementations for driver use cases.
    • Ensure the driver service and controller depend on use cases via tokens.

  • File: apps/api/src/domain/driver/DriverModule.test.ts

    • Update module tests to reflect the wiring of presenters as output ports and the token-based injection of use cases.

DTOs

  • Files: apps/api/src/domain/driver/dtos/CompleteOnboardingInputDTO.ts, CompleteOnboardingOutputDTO.ts, DriverDTO.ts, DriverLeaderboardItemDTO.ts, DriverRegistrationStatusDTO.ts, DriversLeaderboardDTO.ts, DriverStatsDTO.ts, GetDriverOutputDTO.ts, GetDriverProfileOutputDTO.ts, GetDriverRegistrationStatusQueryDTO.ts
    • Ensure these DTOs are used exclusively as API input or response models, and not inside core use cases.
    • Align names and shapes with the response models and input expectations defined in driver presenters and services.

Presenters

  • Files: apps/api/src/domain/driver/presenters/CompleteOnboardingPresenter.ts, DriverPresenter.ts, DriverProfilePresenter.ts, DriverRegistrationStatusPresenter.ts, DriversLeaderboardPresenter.ts, DriverStatsPresenter.ts

    • Ensure each presenter implements the use case output port contract for its driver result model.
    • Ensure each presenter maintains an internal response model that is constructed from the driver result model.
    • Ensure each presenter exposes a getter that returns the response model.
    • Move all driver mapping logic from the driver service into the relevant presenters.
    • Consistently use response model terminology within presenters.

  • Files: apps/api/src/domain/driver/presenters/DriverRegistrationStatusPresenter.test.ts, DriversLeaderboardPresenter.test.ts, DriverStatsPresenter.test.ts

    • Update tests to confirm that presenters correctly transform core result models into driver response models and that no mapping remains in the service.

League domain module

Directory: apps/api/src/domain/league

Controllers

  • File: apps/api/src/domain/league/LeagueController.ts

    • Ensure controller methods expect league response models from the league service and do not depend on internal DTO mapping logic.
    • Align return types with the league response models constructed by presenters.

  • File: apps/api/src/domain/league/LeagueController.test.ts

    • Update tests to verify that controllers interact with the league service via response models and handle errors based on use case Results.

Services

  • File: apps/api/src/domain/league/LeagueService.ts

    • Identify all mapping and DTO construction logic in the league service and move it into league presenters.
    • Ensure service methods delegate output handling entirely to presenters and only return response models.
    • Ensure repositories and use cases are injected via tokens and that no presenter is injected via dependency injection.

  • File: apps/api/src/domain/league/LeagueService.test.ts

    • Update tests to reflect the reduced responsibility of the league service and to verify that it returns response models produced by presenters.

Module and providers

  • (If a LeagueModule file exists in the codebase)
    • Ensure league presenters are registered as providers and bound as output port implementations for league use cases.

DTOs

  • Files: apps/api/src/domain/league/dtos/AllLeaguesWithCapacityAndScoringDTO.ts, ApproveLeagueJoinRequestDTO.ts, GetLeagueRacesOutputDTO.ts, GetLeagueWalletOutputDTO.ts, LeagueAdminDTO.ts, LeagueConfigFormModelDropPolicyDTO.ts, LeagueConfigFormModelStewardingDTO.ts, LeagueMemberDTO.ts, LeagueScoringPresetDTO.ts, MembershipStatusDTO.ts, RejectJoinRequestOutputDTO.ts, WithdrawFromLeagueWalletInputDTO.ts, WithdrawFromLeagueWalletOutputDTO.ts
    • Ensure these DTOs are used only as API-level representations and not referenced by core use cases.
    • Align naming with the response models produced by league presenters.

Presenters

  • Files: apps/api/src/domain/league/presenters/GetLeagueAdminPermissionsPresenter.ts, LeagueScoringPresetsPresenter.ts

    • Ensure each presenter implements the use case output port contract for its league result model.
    • Ensure each presenter constructs and stores a league response model from the core result model and exposes a getter.
    • Move league mapping logic from the league service into these presenters.

  • File: apps/api/src/domain/league/presenters/LeagueOwnerSummaryPresenter.test.ts

    • Update tests to confirm that the presenter is responsible for mapping from core result model to response model and that no mapping remains in the service.

Media domain module

Directory: apps/api/src/domain/media

Controllers

  • File: apps/api/src/domain/media/MediaController.ts

    • Ensure controller methods depend on media service methods that return response models, not core media objects or partial DTOs.
    • Align the controller return types with media response models produced by presenters.

  • File: apps/api/src/domain/media/MediaController.test.ts

    • Update tests to verify that controllers work with media response models returned from the service.

Services

  • File: apps/api/src/domain/media/MediaService.ts
    • Identify all mapping from media domain objects to DTOs and move this logic into media presenters.
    • Ensure each service method calls the relevant media use case, allows it to use presenters via output ports, and returns response models from presenters.
    • Confirm that repositories and use cases are injected via tokens and that no presenter is injected via dependency injection.

Module and providers

  • File: apps/api/src/domain/media/MediaModule.ts

    • Ensure media presenters are registered as providers and bound as output port implementations for media use cases.

  • File: apps/api/src/domain/media/MediaModule.test.ts

    • Update tests to reflect the correct provider wiring and output port bindings.

  • File: apps/api/src/domain/media/MediaProviders.ts

    • Review token definitions for repositories and use cases; ensure they are used consistently for constructor injection.
    • Add or adjust tokens required for output port wiring without introducing presenter tokens for services.

DTOs

  • Files: apps/api/src/domain/media/dtos/DeleteMediaOutputDTO.ts, GetAvatarOutputDTO.ts, GetMediaOutputDTO.ts, RequestAvatarGenerationInputDTO.ts, RequestAvatarGenerationOutputDTO.ts, UpdateAvatarInputDTO.ts, UpdateAvatarOutputDTO.ts, UploadMediaInputDTO.ts, UploadMediaOutputDTO.ts
    • Ensure these DTOs serve only as API input and response models and are not used directly within core use cases.
    • Align naming and structure with the response models built by media presenters.

Presenters

  • Files: apps/api/src/domain/media/presenters/DeleteMediaPresenter.ts, GetAvatarPresenter.ts, GetMediaPresenter.ts, RequestAvatarGenerationPresenter.ts, UpdateAvatarPresenter.ts, UploadMediaPresenter.ts
    • Ensure each presenter implements the use case output port contract for its media result model.
    • Ensure each presenter maintains internal response model state derived from the core result model and exposes a getter.
    • Move all mapping and response model construction from the media service into these presenters.

Types

  • Files: apps/api/src/domain/media/types/FacePhotoData.ts, SuitColor.ts
    • Verify that these types are used appropriately as part of input or response models and not as replacements for core domain entities inside use cases.

Payments domain module

Directory: apps/api/src/domain/payments

Controllers

  • File: apps/api/src/domain/payments/PaymentsController.ts
    • Ensure controller methods call payments use cases via services or directly, receive results that are presented via presenters, and return payments response models.
    • Remove any mapping logic from the controller and rely exclusively on presenters for transforming result models into response models.

Module and providers

  • File: apps/api/src/domain/payments/PaymentsModule.ts

    • Ensure payments presenters are registered as providers and bound as output port implementations for payments use cases.

  • File: apps/api/src/domain/payments/PaymentsModule.test.ts

    • Update module tests to reflect correct output port wiring and token-based use case injection.

  • File: apps/api/src/domain/payments/PaymentsProviders.ts

    • Review token definitions for payments repositories and use cases; ensure they are consistently used for dependency injection.
    • Add or adjust tokens as needed for output port wiring.

DTOs

  • Files: apps/api/src/domain/payments/dtos/CreatePaymentInputDTO.ts, CreatePaymentOutputDTO.ts, MemberPaymentStatus.ts, MembershipFeeType.ts, PayerType.ts, PaymentDTO.ts, PaymentsDto.ts, PaymentStatus.ts, PaymentType.ts, PrizeType.ts, ReferenceType.ts, TransactionType.ts, UpdatePaymentStatusInputDTO.ts, UpdatePaymentStatusOutputDTO.ts
    • Ensure these DTOs are used solely as API-level input and response models and not within core payments use cases.
    • Align naming and structure with the response models and inputs expected by payments presenters and services.

Presenters

  • (Any payments presenters, once identified or added during implementation)
    • Ensure they implement the use case output port contract, maintain internal response model state, and expose getters for response models.
    • Centralize all payments mapping logic in these presenters.

Protests domain module

Directory: apps/api/src/domain/protests

Controllers

  • File: apps/api/src/domain/protests/ProtestsController.ts
    • Ensure controller methods rely on protests service methods that return response models, avoiding any direct mapping from domain objects.
    • Align controller return types with protests response models produced by presenters.

Services

  • File: apps/api/src/domain/protests/ProtestsService.ts

    • Identify all mapping logic in the protests service and move it into protests presenters.
    • Ensure each service method calls the appropriate protests use case, lets it use presenters through output ports, and returns response models from presenters.
    • Confirm that protests repositories and use cases are injected via tokens only.
    • Ensure no protests presenter is injected into the service via dependency injection.

  • File: apps/api/src/domain/protests/ProtestsService.test.ts

    • Update tests to reflect the reduced responsibility of the protests service and its reliance on presenters for response model creation.

Module and providers

  • File: apps/api/src/domain/protests/ProtestsModule.ts

    • Ensure protests presenters are registered as providers and bound as output port implementations for protests use cases.

  • File: apps/api/src/domain/protests/ProtestsProviders.ts

    • Review token definitions and usage for protests repositories and use cases and ensure consistent usage for injection.
    • Add or adjust tokens for output port wiring.

Presenters

  • (Any protests presenters to be added or identified during implementation)
    • Ensure they implement the use case output port contract, maintain internal response model state, and expose getters for response models.

Race domain module

Directory: apps/api/src/domain/race

Controllers

  • File: apps/api/src/domain/race/RaceController.ts

    • Ensure controller methods call race service methods that return response models and do not perform any mapping from race domain entities.
    • Adjust controller return types to reflect race response models created by presenters.

  • File: apps/api/src/domain/race/RaceController.test.ts

    • Update tests so they verify controller behavior in terms of response models and error handling based on use case Results.

Services

  • File: apps/api/src/domain/race/RaceService.ts

    • Identify all mapping logic from race domain entities to DTOs and move it into race presenters.
    • Ensure each service method calls the relevant race use case, lets it present through race presenters, and returns response models from presenters.
    • Confirm race repositories and use cases are injected via tokens only and that no presenter is injected via dependency injection.

  • File: apps/api/src/domain/race/RaceService.test.ts

    • Update tests to reflect that the race service now delegates mapping to presenters and returns response models.

Module and providers

  • File: apps/api/src/domain/race/RaceModule.ts

    • Ensure race presenters are registered as providers and bound as output port implementations for race use cases.

  • File: apps/api/src/domain/race/RaceModule.test.ts

    • Update tests to confirm correct wiring of race presenters and token-based use case injection.

  • File: apps/api/src/domain/race/RaceProviders.ts

    • Verify token definitions for race repositories and use cases and ensure consistent usage.
    • Add or adjust tokens to support output port wiring.

DTOs

  • Files: apps/api/src/domain/race/dtos/AllRacesPageDTO.ts, DashboardDriverSummaryDTO.ts, DashboardFeedSummaryDTO.ts, DashboardFriendSummaryDTO.ts, DashboardLeagueStandingSummaryDTO.ts, DashboardOverviewDTO.ts, DashboardRaceSummaryDTO.ts, DashboardRecentResultDTO.ts, FileProtestCommandDTO.ts, GetRaceDetailParamsDTO.ts, ImportRaceResultsDTO.ts, ImportRaceResultsSummaryDTO.ts, QuickPenaltyCommandDTO.ts, RaceActionParamsDTO.ts, RaceDetailDTO.ts, RaceDetailEntryDTO.ts, RaceDetailLeagueDTO.ts, RaceDetailRaceDTO.ts, RaceDetailRegistrationDTO.ts, RaceDetailUserResultDTO.ts, RacePenaltiesDTO.ts, RacePenaltyDTO.ts, RaceProtestDTO.ts, RaceProtestsDTO.ts, RaceResultDTO.ts, RaceResultsDetailDTO.ts, RacesPageDataDTO.ts, RacesPageDataRaceDTO.ts, RaceStatsDTO.ts, RaceWithSOFDTO.ts, RegisterForRaceParamsDTO.ts, RequestProtestDefenseCommandDTO.ts, ReviewProtestCommandDTO.ts, WithdrawFromRaceParamsDTO.ts
    • Ensure these DTOs serve exclusively as API-level input and response models and are not used directly by core race use cases.
    • Align naming and structures with race response models produced by presenters.

Presenters

  • Files: apps/api/src/domain/race/presenters/AllRacesPageDataPresenter.ts, GetAllRacesPresenter.ts, GetTotalRacesPresenter.ts, ImportRaceResultsApiPresenter.ts, RaceDetailPresenter.ts, RacePenaltiesPresenter.ts, RaceProtestsPresenter.ts, RaceWithSOFPresenter.ts

    • Ensure each race presenter implements the use case output port contract for its race result model.
    • Ensure each presenter maintains internal response model state derived from core race result models and exposes getters.
    • Move all race mapping logic and DTO construction from the race service into these presenters.
    • Use response model terminology consistently within presenters.

  • File: apps/api/src/domain/race/presenters/GetAllRacesPresenter.test.ts

    • Update tests so they validate presenter-based mapping from core race result models to race response models and reflect the absence of mapping logic in the service.

Sponsor domain module

Directory: apps/api/src/domain/sponsor

Controllers

  • File: apps/api/src/domain/sponsor/SponsorController.ts
    • Ensure controller methods depend on sponsor service methods that return sponsor response models and avoid direct mapping.
    • Align controller return types with sponsor response models constructed by presenters.

Services

  • File: apps/api/src/domain/sponsor/SponsorService.ts

    • Identify and move all sponsor mapping and DTO construction from the service into sponsor presenters.
    • Ensure service methods call sponsor use cases, allow presenters to handle output via output ports, and return response models from presenters.
    • Confirm sponsor repositories and use cases are injected via tokens only, with no presenter injection.

  • File: apps/api/src/domain/sponsor/SponsorService.test.ts

    • Update tests to reflect that sponsor services return response models created by presenters and no longer perform mapping.

Module and providers

  • File: apps/api/src/domain/sponsor/SponsorModule.ts

    • Ensure sponsor presenters are registered as providers and bound as output port implementations for sponsor use cases.

  • File: apps/api/src/domain/sponsor/SponsorProviders.ts

    • Review token definitions and usage for sponsor repositories and use cases and adjust as needed for output port wiring.

Presenters

  • (Any sponsor presenters present or added during implementation)
    • Ensure they implement the use case output port contract, maintain internal response model state, and expose getters for response models.

Team domain module

Directory: apps/api/src/domain/team

DTOs

  • Files: apps/api/src/domain/team/dtos/GetTeamDetailsOutputDTO.ts, UpdateTeamOutputDTO.ts
    • Ensure these DTOs are used exclusively as API response models and are not referenced directly by core team use cases.
    • Align naming and fields with response models created by team presenters.

Presenters

  • Files: apps/api/src/domain/team/presenters/AllTeamsPresenter.ts, CreateTeamPresenter.ts, DriverTeamPresenter.ts, TeamDetailsPresenter.ts
    • Ensure each team presenter implements the use case output port contract for its corresponding team result model.
    • Ensure each presenter maintains internal response model state created from core team result models and exposes response model getters.
    • Move any team mapping or DTO-construction logic from any related services or controllers into these presenters.

Services and controllers (if located elsewhere)

  • (Any services or controllers that use the team presenters found in other modules)
    • Ensure these services and controllers treat team presenters as output ports, do not inject presenters directly, and return only response models from presenters.

Final global verification

  • Run project-wide type checking and resolve any remaining type errors related to use case output ports, presenters, and response models.
  • Run project-wide linting and fix all issues related to unused imports, incorrect injection tokens, or outdated DTO usage.
  • Run the full test suite and ensure that all module tests pass after the migration.
  • Perform a final review of the API layer to confirm that all mapping from domain objects to API representations is performed by presenters, that services are orchestration-only, and that use cases present via output ports and return Result types without performing serialization.
Reference in New Issue View Git Blame Copy Permalink