Problem
ScheduleRemoteDataSource and ScheduleLocalDataSource currently accept and return ScheduleEntity directly. That makes the data source layer responsible for domain-to-DTO and domain-to-persistence mapping, instead of keeping transport/persistence concerns behind data-layer models and letting the repository adapt them to domain entities.
Evidence
lib/data/data_sources/schedule_remote_data_source.dart imports ScheduleEntity and exposes it in the remote data source contract for create, read, update, and delete operations.
- The remote data source converts domain entities into request models and API response models back into
ScheduleEntity before returning.
lib/data/data_sources/schedule_local_data_source.dart imports ScheduleEntity and exposes it in the local data source contract.
- The local data source converts between
ScheduleEntity and Drift/data models.
lib/domain/entities/schedule_entity.dart contains persistence mapping helpers used by the local data source, which further couples the domain entity to data-layer table types.
Proposed direction
Move schedule mapping to the repository/data-mapper seam:
- Keep
ScheduleRepositoryImpl as the place that exposes and consumes ScheduleEntity.
- Change
ScheduleRemoteDataSource to accept request DTOs or primitive command arguments and return response DTOs.
- Change
ScheduleLocalDataSource to accept and return Drift/data-layer models such as Schedule, ScheduleWithPlace, or dedicated local models.
- Move
ScheduleEntity conversion helpers into data-layer mapper extensions or mapper classes so domain entities do not import data-layer persistence types.
Acceptance criteria
ScheduleRemoteDataSource no longer imports domain/entities/schedule_entity.dart.
ScheduleLocalDataSource no longer imports domain/entities/schedule_entity.dart.
ScheduleRepositoryImpl preserves the existing public ScheduleRepository domain API while handling schedule entity mapping explicitly.
- Schedule remote/local data source tests are updated to assert DTO/local-model contracts instead of domain entity contracts.
- Existing schedule repository behavior remains covered by repository tests for create, update, delete, get-by-id, and get-by-date flows.
Source: Codex codebase audit on 2026-06-28.
Problem
ScheduleRemoteDataSourceandScheduleLocalDataSourcecurrently accept and returnScheduleEntitydirectly. That makes the data source layer responsible for domain-to-DTO and domain-to-persistence mapping, instead of keeping transport/persistence concerns behind data-layer models and letting the repository adapt them to domain entities.Evidence
lib/data/data_sources/schedule_remote_data_source.dartimportsScheduleEntityand exposes it in the remote data source contract for create, read, update, and delete operations.ScheduleEntitybefore returning.lib/data/data_sources/schedule_local_data_source.dartimportsScheduleEntityand exposes it in the local data source contract.ScheduleEntityand Drift/data models.lib/domain/entities/schedule_entity.dartcontains persistence mapping helpers used by the local data source, which further couples the domain entity to data-layer table types.Proposed direction
Move schedule mapping to the repository/data-mapper seam:
ScheduleRepositoryImplas the place that exposes and consumesScheduleEntity.ScheduleRemoteDataSourceto accept request DTOs or primitive command arguments and return response DTOs.ScheduleLocalDataSourceto accept and return Drift/data-layer models such asSchedule,ScheduleWithPlace, or dedicated local models.ScheduleEntityconversion helpers into data-layer mapper extensions or mapper classes so domain entities do not import data-layer persistence types.Acceptance criteria
ScheduleRemoteDataSourceno longer importsdomain/entities/schedule_entity.dart.ScheduleLocalDataSourceno longer importsdomain/entities/schedule_entity.dart.ScheduleRepositoryImplpreserves the existing publicScheduleRepositorydomain API while handling schedule entity mapping explicitly.Source: Codex codebase audit on 2026-06-28.