Travel Supplier Adapter Pattern

Supplier adapter pattern'ın amacı her provider farkını core domain'e yaymak değil, provider contract'ını kontrollü bir boundary içinde tutmaktır.

Production senaryosu

Bir sistem Expedia, Booking connectivity, direct hotel API ve başka bir wholesaler ile çalışıyor. Her biri farklı auth, request DTO, error code ve pricing semantics kullanıyor.

Önerilen boundary

Core Search Service
   -> ISupplierAdapter
      -> Provider Request Mapper
      -> HTTP/API Client
      -> Provider Response Mapper
      -> Error Translator
      -> Capability Metadata

Adapter contract

Örnek sorumluluklar:

• Supports(context)
• Search(context)
• Reprice(offerRef)
• Book(request) — varsa
• Cancel(reference) — varsa
• Health()

Adapter generic bir “her şeyi yapan service” olmamalıdır.

Data model

Core domain:

• SearchContext
• NormalizedOffer
• SupplierReference
• Money
• CancellationPolicy
• AvailabilityState

Provider DTO'ları adapter dışında kullanılmamalıdır.

Trade-off

Çok soyut adapter interface provider capability farklarını saklayabilir. Çok provider-specific interface ise core katmanı kirletir.

Çözüm: küçük ortak contract + capability metadata + gerektiğinde optional capability interface.

Error handling

Provider error code'larını tek “500”e çevirmeyin. En az şu sınıflar ayrılmalı:

• auth
• rate limit
• timeout
• invalid request
• no availability
• upstream unavailable
• retryable technical failure
• non-retryable business failure

Versioning

Provider API version değiştiğinde core servisin değil adapter implementation'ın değişmesi hedeflenmelidir. Old/new version paralel çalıştırılabiliyorsa shadow traffic ile karşılaştırın.

Failure modes

• source ID kaybı,
• provider-specific policy'nin normalize edilirken silinmesi,
• yanlış retry,
• adapter içinde business ranking logic,
• one-off hack'lerin core modele sızması.

Observability

Her adapter için latency, success, retry, normalized-offer count, mapping failures ve raw-to-normalized validation error izleyin.

Ne zaman kullanmamalı?

Tek provider'lı küçük bir prototipte tam adapter framework over-engineering olabilir. Ancak ikinci provider geldiği anda explicit boundary'nin değeri hızla artar.

Production checklist

• provider DTO isolation
• explicit capabilities
• error taxonomy
• raw/source reference preservation
• provider-specific timeout/retry
• contract tests
• version migration plan
• per-adapter metrics