Skip to content

Decouple domain entities from data, core, and presentation types #525

Description

@jjoonleo

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    codex-readyCan be started independently by a Codex thread nowproduction-readinessWork required before production releaserefactor

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions