Purpose

This note records the persistence/read boundary after Sprint 07. The service still has a large mixed TendersRepository, but active runtime reads are no longer all hidden inside it.

Active Repository Shape

Central mixed repository

File:

• services/svc-tenders/src/repository.ts

Class:

• TendersRepository

Still owns a broad MIXED set of responsibilities, including:

• tender persistence
• auction declaration persistence
• ICPI persistence
• Butkhuzi persistence
• KES-related persistence
• outbox/event persistence
• some legacy vacancy/accommodation compatibility readers

This file is still oversized and cross-domain.

Active vacancy read repository

File:

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

Class:

• VacancyReadRepository

Now owns the active runtime vacancy read path used by HTTP routes for:

• public vacancy list/detail
• owner vacancy posting reads
• applicant vacancy reads
• owner vacancy application reads

Important truth:

• this repository is still MIXED
• it intentionally preserves projection + legacy catalog fallback behavior from older TendersRepository methods
• that fallback is now explicit in naming/comments instead of hidden behind the central repository

Active accommodation public/booking read repository

File:

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

Class:

• AccommodationReadRepository

Active runtime owner/public/booking read path for:

• public accommodation list/detail
• quote source data
• owner reservation reads
• requester booking reads
• listing booking reads

Important truth:

• this is the most honest active accommodation read path currently in use
• Sprint 07 switched booking-read endpoints to this repository instead of fake empty arrays

Active accommodation owner listing read repository

File:

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

Class:

• AccommodationOwnerReadRepository

Now owns the active runtime owner listing reads for:

• /owner/accommodation-listings
• /owner/accommodation-listings/:id

This is a small boundary cleanup, not a domain extraction.

Legacy Compatibility Methods Left In TendersRepository

Sprint 07 intentionally did not delete these methods from repository.ts:

Vacancy compatibility readers:

• listAllVacancies
• countAllVacancies
• findVacancyById
• listMyVacancyPostings
• findMyVacancyPostingById
• listMyVacancyApplications
• listVacancyApplicationsByPosting
• listOwnerVacancyApplications
• getOwnerVacancyApplication

Accommodation compatibility readers:

• listAllAccommodations
• countAllAccommodations
• findAccommodationById
• listMyAccommodationListings
• findMyAccommodationListingById

Why they remain:

• lower-risk cleanup for this sprint
• tests and older internal call sites may still depend on them
• deletion would widen scope from boundary cleanup into behavioral refactor

What changed:

• these methods are now explicitly labeled as legacy compatibility residue where active runtime paths have moved elsewhere

Boundary Verdict

Clearly improved

• active vacancy HTTP reads no longer have to go through TendersRepository
• active owner accommodation listing reads no longer have to go through TendersRepository
• accommodation booking reads now use the real accommodation read model

Still unresolved

• TendersRepository remains a domain monolith
• event/outbox persistence is still colocated with multiple domains
• ambiguous ownership areas like output_allocations were intentionally not moved

What Should Happen Next

Recommended next repository cleanup:

• split tender/declaration persistence from ICPI/Butkhuzi/KES persistence
• keep vacancy/accommodation compatibility methods only until runtime callers and tests are fully moved
• avoid deleting compatibility readers until route and test migration is complete