Problem
Domain entities currently depend on lower-level persistence models and presentation-only UI state. lib/domain/entities should stay independent of data, core/database, and presentation so domain behavior can be tested and reused without Drift tables, data DTOs, or UI constants.
Evidence
lib/domain/entities/schedule_entity.dart imports data/tables/schedule_with_place_model.dart and core/database/database.dart.
ScheduleEntity contains persistence mapping methods such as fromScheduleWithPlaceModel, toScheduleModel, and toScheduleWithPlaceModel.
lib/domain/entities/preparation_with_time_entity.dart imports presentation/shared/constants/constants.dart and returns List<PreparationStateEnum>.
- Adjacent entities show the same pattern: place, preparation step, and user entities import Drift/core database models or expose
fromModel/toModel methods.
Proposed direction
Move persistence conversion out of domain entities and into the data layer, preferably as mapper extensions/adapters near DAOs, local data sources, or data models. Keep domain entities expressed only in domain types and Dart primitives.
For preparation step state, either move the enum into the domain layer under a domain-oriented name if it represents business state, or keep it in presentation and map from domain timing data into UI state inside presentation/view-model code.
Acceptance criteria
lib/domain/entities has no imports from lib/core, lib/data, or lib/presentation.
- Domain entities no longer expose Drift/data model mapping methods such as
fromModel, toModel, fromScheduleWithPlaceModel, toScheduleModel, or toPreparationUserModel.
- Schedule, place, user, and preparation persistence mappings live in the data layer and existing DAO/local data source call sites are updated.
- Preparation timing UI state is derived without importing presentation constants into the domain layer.
- Add or update focused tests for mapper behavior and preparation timing state derivation.
flutter analyze and relevant domain/data tests pass.
Source: Codex codebase audit on 2026-06-28.
Problem
Domain entities currently depend on lower-level persistence models and presentation-only UI state.
lib/domain/entitiesshould stay independent ofdata,core/database, andpresentationso domain behavior can be tested and reused without Drift tables, data DTOs, or UI constants.Evidence
lib/domain/entities/schedule_entity.dartimportsdata/tables/schedule_with_place_model.dartandcore/database/database.dart.ScheduleEntitycontains persistence mapping methods such asfromScheduleWithPlaceModel,toScheduleModel, andtoScheduleWithPlaceModel.lib/domain/entities/preparation_with_time_entity.dartimportspresentation/shared/constants/constants.dartand returnsList<PreparationStateEnum>.fromModel/toModelmethods.Proposed direction
Move persistence conversion out of domain entities and into the data layer, preferably as mapper extensions/adapters near DAOs, local data sources, or data models. Keep domain entities expressed only in domain types and Dart primitives.
For preparation step state, either move the enum into the domain layer under a domain-oriented name if it represents business state, or keep it in presentation and map from domain timing data into UI state inside presentation/view-model code.
Acceptance criteria
lib/domain/entitieshas no imports fromlib/core,lib/data, orlib/presentation.fromModel,toModel,fromScheduleWithPlaceModel,toScheduleModel, ortoPreparationUserModel.flutter analyzeand relevant domain/data tests pass.Source: Codex codebase audit on 2026-06-28.