---
title: "Travel Supplier Adapter Pattern"
description: "Hotel ve flight supplier entegrasyonlarını provider-specific DTO'lardan ayıran adapter contract, normalization, error ve versioning tasarımını kurun."
slug: "supplier-adapter-pattern"
translationKey: "architecture-supplier-adapter-pattern"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["adapter","supplier","integration","architecture","normalization"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

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

```text
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