Vacancy / Accommodation Compatibility Boundary

Purpose

Sprint 13 moved the remaining vacancy/accommodation compatibility reads out of services/svc-tenders/src/repository.ts and into explicitly named compatibility modules.

This was a structural move only.

It did not change:

• final ownership
• runtime route contracts
• preferred read-model ownership
• public behavior

Vacancy boundary

Preferred path

VERIFIED preferred vacancy reads live in:

• services/svc-tenders/src/vacancy/readRepository.ts

That repository already owns:

• listAllVacancies(...)
• countAllVacancies(...)
• findVacancyById(...)
• listMyVacancyPostings(...)
• findMyVacancyPostingById(...)

Compatibility path

Sprint 13 created:

• services/svc-tenders/src/vacancy/compatibilityReadRepository.ts

This module is intentionally second-class.

Its role is:

• preserve the older TendersRepository compatibility surface
• keep that surface explicit instead of leaving vacancy compatibility reads embedded in the root mixed repository

How vacancy compatibility works now

VacancyCompatibilityReadRepository delegates to the already-preferred:

• VacancyReadRepository

This is truthful because the compatibility concern is now the surface, not a separate legacy SQL implementation.

Accommodation boundary

Preferred paths

VERIFIED preferred accommodation reads now live in:

• public published-listing reads:
  • services/svc-tenders/src/accommodation/readModel.ts
  • class: AccommodationReadRepository
• owner listing reads:
  • services/svc-tenders/src/accommodation/ownerReadRepository.ts
  • class: AccommodationOwnerReadRepository

Compatibility path

Sprint 13 created:

• services/svc-tenders/src/accommodation/compatibilityReadRepository.ts

This module is intentionally second-class.

It preserves older compatibility behavior that still reads from the legacy accommodations catalog for:

• listAllAccommodations(...)
• countAllAccommodations(...)
• findAccommodationById(...)

It delegates owner listing compatibility methods to:

• AccommodationOwnerReadRepository

for:

• listMyAccommodationListings(...)
• findMyAccommodationListingById(...)

Why accommodation compatibility is different from vacancy compatibility

Vacancy compatibility in practice was mostly a compatibility wrapper around an already-preferred repository.

Accommodation compatibility still preserves a genuinely different legacy read source:

• preferred public path: accommodation_listings_view / accommodation_listing_detail_view
• compatibility path: legacy accommodations catalog table

That distinction is now explicit in module naming.

What moved

Out of services/svc-tenders/src/repository.ts:

• vacancy compatibility read methods
• accommodation compatibility read methods
• the row mappers and helper functions that existed only to support those methods

What remains preferred vs compatibility

Preferred

• services/svc-tenders/src/vacancy/readRepository.ts
• services/svc-tenders/src/accommodation/readModel.ts
• services/svc-tenders/src/accommodation/ownerReadRepository.ts

Compatibility

• services/svc-tenders/src/vacancy/compatibilityReadRepository.ts
• services/svc-tenders/src/accommodation/compatibilityReadRepository.ts
• delegation methods still exposed on TendersRepository for stability

What remains unresolved

Still unresolved after Sprint 13:

• final long-term ownership of vacancy/worker/accommodation/workstay platform boundaries
• whether the TendersRepository compatibility surface should later be retired entirely
• whether accommodation legacy catalog reads should eventually be removed once no callers depend on them

Result

The preferred read paths and compatibility read paths are now easier to distinguish:

• preferred paths live in the domain read repositories
• compatibility paths live in explicitly named compatibilityReadRepository modules
• root repository.ts delegates instead of embedding those behaviors inline