Parent Issue / 親Issue
#555
Motivation / 目的
Implement the Application layer use cases for listing favorite heritages and returning favorite ids, as part of #555.
お気に入り一覧・ID一覧取得API（#555）のApplication層として、UseCaseを実装します。
What to do / 実施内容
QueryUseCases
ListMyFavoritesUseCase
GetFavoriteHeritageIdsUseCase
FavoriteRepositoryInterface::findHeritageIdsByUserId() の結果をそのまま返す薄いUseCase
Pagination approach for ListMyFavoritesUseCase
Favorites are bounded by the total World Heritage catalog size (~1,200 sites) and are scoped per user, so the count involved is always small. Because of that, this fetches all favorite IDs and paginates in application code rather than adding a new DB-level paginate() join method to the repository:
$allIds = $favoriteRepository->findHeritageIdsByUserId($userId); // all ids, ordered by favorited-at desc
$total = count($allIds);
$pageIds = array_slice($allIds, ($currentPage - 1) * $perPage, $perPage);
$heritages = $worldHeritageReadQueryService->findByIdsPreserveOrder($pageIds);
$lastPage = (int) ceil($total / $perPage);
Build the pagination metadata (current_page, per_page, total, last_page, from, to, page URLs) by hand, matching the same key structure as the existing PaginationDto::toArray() used by /v1/heritages (items + pagination), rather than wrapping an Eloquent LengthAwarePaginator.
Trade-off: this skips reusing Eloquent's paginator (so URL/meta fields are computed manually instead of generated automatically), but avoids adding a join-based pagination method to FavoriteRepositoryInterface. If favorite counts were ever expected to grow far beyond the heritage catalog size, this assumption would need to be revisited in favor of a DB-level join + paginate().
Tests / テスト
Mockeryを使ったユニットテスト
test_handle_returns_favorite_heritages_for_usertest_handle_returns_empty_list_when_no_favoritestest_handle_paginates_favorite_heritages_correctlytest_handle_returns_favorite_ids_for_usertest_handle_returns_empty_array_when_no_favorites
Parent Issue / 親Issue
#555
Motivation / 目的
Implement the Application layer use cases for listing favorite heritages and returning favorite ids, as part of #555.
お気に入り一覧・ID一覧取得API（#555）のApplication層として、UseCaseを実装します。
What to do / 実施内容
QueryUseCases
ListMyFavoritesUseCaseFavoriteRepositoryInterface::findHeritageIdsByUserId()でお気に入りのIDを取得（feat: implement Domain layer for Favorite Heritage API / お気に入りAPIのDomain層実装 #551/#552で実装済み）WorldHeritageReadQueryServiceInterface::findByIdsPreserveOrder()で世界遺産データを取得GetFavoriteHeritageIdsUseCaseFavoriteRepositoryInterface::findHeritageIdsByUserId()の結果をそのまま返す薄いUseCasePagination approach for
ListMyFavoritesUseCaseFavorites are bounded by the total World Heritage catalog size (~1,200 sites) and are scoped per user, so the count involved is always small. Because of that, this fetches all favorite IDs and paginates in application code rather than adding a new DB-level
paginate()join method to the repository:Build the
paginationmetadata (current_page,per_page,total,last_page,from,to, page URLs) by hand, matching the same key structure as the existingPaginationDto::toArray()used by/v1/heritages(items+pagination), rather than wrapping an EloquentLengthAwarePaginator.Trade-off: this skips reusing Eloquent's paginator (so URL/meta fields are computed manually instead of generated automatically), but avoids adding a join-based pagination method to
FavoriteRepositoryInterface. If favorite counts were ever expected to grow far beyond the heritage catalog size, this assumption would need to be revisited in favor of a DB-level join +paginate().Tests / テスト
Mockeryを使ったユニットテスト
test_handle_returns_favorite_heritages_for_usertest_handle_returns_empty_list_when_no_favoritestest_handle_paginates_favorite_heritages_correctlytest_handle_returns_favorite_ids_for_usertest_handle_returns_empty_array_when_no_favorites