Rehber

Sistem Entegrasyonu: POS, E-ticaret, Banka ve E-fatura Rehberi

Koray Çetintaş 10 Şubat 2026 15 dk okuma


Entegrasyon Mimarisi Temelleri

Sistem entegrasyonu network yapısi

Entegrasyon mimarisi, farklı sistemleri birbirine bağlayan ömürgadir

Sistem entegrasyonu mimarisi, birbirinden bağımsız çalışacak şekilde tasarlanmış yazılım sistemlerinin veri ve işlem paylaşımı yapabilmesini sağlayan teknik yapıdır. Bu mimarı su temel bileşenleri içerir:

Mimarı Bileşenler

  • Kaynak sistemler (Source): Veriyi üreten sistemler (POS, e-ticaret, üretim)
  • Hedef sistemler (Target): Veriyi tüketen sistemler (ERP, muhasebe, raporlama)
  • Entegrasyon katmanı: Sistemler arasında veri taşıma, dönüştürme ve yönetme
  • Veri formatları: JSON, XML, CSV, EDIFACT gibi standartlar
  • İ̇letişim protokolleri: HTTP/HTTPS, FTP/SFTP, AS2, AMQP, MQTT

Entegrasyon Topolojileri

1. Point-to-Point (Noktadan Noktaya)

Her sistem birbirine doğrudan bağlanır. Az sayıda sistem için basit, ancak sistem sayısı arttikca yönetim zorlaşır. N sistem için N*(N-1)/2 bağlantı gerekir.

2. Hub-and-Spoke (Merkez ve Kol)

Tüm sistemler merkezi bir hub’a (middleware) bağlanır. Yönetim kolaylaşır, ancak hub tek hata noktasi (single point of failure) olabilir.

3. Enterprise Service Bus (ESB)

Dağıtık mimarı ile mesaj yönlendirme, dönüşüm ve orkestrasyon sağlar. Büyük ölçekli kurumsal sistemler için uygundur.

4. Event-Driven Architecture (EDA)

Sistemler olayları (event) yayınlar ve dinler. Geniş capta ölçeklenebilirlik ve gevset bağlılık (loose coupling) sağlar.

Ipucu

Küçük ve orta ölçekli işletmeler için Hub-and-Spoke veya modern iPaaS (Integration Platform as a Service) çözümleri genellikle en uygun maliyetli seçenektir.


API Entegrasyonu: REST, SOAP, GraphQL

API entegrasyonu kod ekranı

API’ler modern entegrasyonun temel yapı taslarıdır

API (Application Programming Interface), sistemlerin birbirleriyle programatik olarak iletişim kurmasını sağlayan arabirimdir. Farklı API türleri farklı senaryolara uygundur:

REST API

Representational State Transfer (REST), HTTP protokolü üzerine kurulu, durumsuz (stateless) mimarıdır. Günümüzde en yaygın kullanılan API tipidir.

  • HTTP metodları: GET (okuma), POST (oluşturma), PUT/PATCH (güncelleme), DELETE (silme)
  • Veri formatı: Genellikle JSON, bazen XML
  • Avantajlar: Basitlik, yaygın destek, kolay debug
  • Kullanım alanları: E-ticaret, mobil uygulamalar, SaaS entegrasyonları

SOAP API

Simple Object Access Protocol (SOAP), XML tabanlı, katı standartlara sahip protokoldür. Kurumsal sistemlerde ve bankacilikte hala kullanılır.

  • Veri formatı: XML (WSDL ile tanimli)
  • Güvenlik: WS-Security ile gelişmiş güvenlik
  • Avantajlar: Transaction desteği, ACID uyumluluk, tıp güvenliği
  • Kullanım alanları: Banka entegrasyonları, kurumsal ERP sistemleri

GraphQL

Facebook tarafından geliştirilen, istemcinin ihtiyacı olan veriyi tanımladigi sorgu dili ve çalışma ortamidir.

  • Özellik: Tek endpoint, esnek sorgular
  • Avantajlar: Over-fetching/under-fetching önleme, versiyon yönetimi kolaylığı
  • Kullanım alanları: Modern frontend uygulamaları, mobil API’ler

API Entegrasyonu En Iyi Pratikleri

  • Her zaman HTTPS kullanın, HTTP asla
  • API anahtarları veya OAuth 2.0 ile kimlik doğrulama yapın
  • Rate limiting (hız sınırlaması) uygulayarak istismar önleyin
  • Versiyon yönetimi ile geriye dönük uyumluluk sağlayIn (v1, v2)
  • Kapsamlı hata kodları ve mesajları döndürün
  • API dokümantasyonunu güncel tutun (OpenAPI/Swagger)

Middleware (Ara Katman) Mimarisi

Middleware veri akisi

Middleware, sistemler arası iletişimi yöneten köprü görevidir

Middleware, kaynak ve hedef sistemler arasında duran, veri dönüşümu, yönlendirme ve orkestrasyon görevlerini üstlenen yazılım katmanıdır. Neden önemlidir?

Middleware Avantajları

  • Gevsek bağlılık (Loose Coupling): Sistemler birbirini doğrudan tanımak zorunda kalmaz
  • Veri dönüşümu: Farklı formatlar arası çeviri (JSON – XML – CSV)
  • Protokol cevirisi: HTTP – SFTP – AS2 – MQ arası geçiş
  • Kuyruk yönetimi: Asenkron işlem ve yük dengeleme
  • Hata yönetimi: Retry, dead letter queue, circuit breaker
  • Izleme ve loglama: Merkezi gözlem noktasi

Middleware Türleri

1. Message Broker

Mesaj kuyruğu yönetimi sağlar. Sistemler mesaj üretir (producer) ve tüketir (consumer). Apache Kafka, RabbitMQ, Azure Service Bus örneklerindendir.

2. Enterprise Service Bus (ESB)

Mesaj yönlendirme, dönüşüm, orkestrasyon ve protokol cevirisi sağlar. MuleSoft, IBM Integration Bus, WSO2 örneklerindendir.

3. iPaaS (Integration Platform as a Service)

Bulut tabanlı entegrasyon platformu. Hazır konektor, görsel tasarımcı, yönetilen altyapı sağlar. Zapier, Make (Integromat), Boomi, Workato örneklerindendir.

Middleware Seçim Kriterleri

  • Sistemlerinizin ölçeği ve karmaşıklığı
  • Teknik ekip yetkinliği
  • On-premise vs bulut tercihi
  • Bütçe ve lisans modelı
  • Hazır konektor sayısı ve kalitesi
  • Izleme ve debug yetenekleri

Dikkat

Middleware seçimi, uzun vadeli bir karardır. Ucuz ve basit başlayıp sonra değiştirmek maliyetli olabilir. Gelecek ihtiyaçları da göz önünde bulundurun.


Real-time vs Batch Entegrasyon

Veri akisi dashboard

Doğru zamanlama seçimi, entegrasyon başarısini belirler

Entegrasyon mimarisinde kritik kararlardan biri, verinin ne zaman transfer edileceğini belirlemektir. Iki temel yaklaşim vardır:

Real-time (Gerçek Zamanlı) Entegrasyon

Veri, olay gerçeklestigi anda anında transfer edilir.

Avantajları:

  • Anlık veri tutarlılığı
  • Hızlı is süreçleri
  • Kullanıcı deneyimi iyileşmesi

Dezavantajları:

  • Sistem yükü artar
  • Hedef sistem kesintilerinde veri kaybı riskı
  • Daha karmaşık hata yönetimi

Kullanım Alanları:

  • POS satışlarinin ERP’ye anında yansimesi
  • E-ticaret sipariş bildirimlerI
  • Stok seviyesi alarmları
  • Ödeme işlemleri

Batch (Toplu) Entegrasyon

Veri, belirli aralıklarla (saatlik, günlük) topluca transfer edilir.

Avantajları:

  • Sistem yükünü azaltır
  • Hata toleransı (retry imkanı)
  • Büyük veri hacimleri için verimli
  • Daha basit hata yönetimi

Dezavantajları:

  • Veri gecikmesi (latency)
  • Geçici tutarsızlık

Kullanım Alanları:

  • Günlük stok senkronizasyonu
  • Muhasebe kapanis işlemleri
  • Raporlama veri güncelleme
  • Ana veri (master data) aktarımı

Hibrit Yaklaşim

Çoğu kurumsal sistemde her iki yaklaşim birlikte kullanılır:

  • Kritik işlemler (sipariş, ödeme) real-time
  • Yoğun veri hacimleri (raporlama, arşiv) batch
  • Near real-time (yakın gerçek zaman) ara çözüm (temsili: 5-15 dakika aralık)

Webhook ve Event-Driven Patterns

Event notification sistemi

Webhook’lar, olay tabanlı entegrasyonun temel aracıdır

Webhook, bir sistemde olay gerçeklestiginde otomatik olarak başka bir sisteme HTTP POST isteği gönderen mekanizmadir. Polling (sürekli sorgulama) yerine push (itme) modelı kullanır.

Webhook Nasıl Çalışır?

  1. Hedef sistem bir URL (endpoint) oluşturur ve kaynak sisteme kaydeder
  2. Kaynak sistemde tanımlanan olay gerçeklesir (örnegin yeni sipariş)
  3. Kaynak sistem, hedef URL’ye HTTP POST isteği gönderir
  4. Hedef sistem isteği alır, işler ve onay (200 OK) döndürür

Webhook Avantajları

  • Kaynak verimliliği: Sürekli sorgulama yerine sadece olay olduğunda iletişim
  • Anında bildirim: Gerçek zamanlı entegrasyon
  • Basitlik: Standart HTTP protokolü

Webhook Zorluklar

  • Teslimat garantisi: Hedef sistem cevap vermezse ne olur?
  • Sıralama: Mesajlar sırasıyla mi ulaşıyor?
  • Idempotency: Aynı mesaj birden fazla gelirse?
  • Güvenlik: Webhook istekleri doğrulanmalı

Webhook En Iyi Pratikleri

  • Her webhook isteği için benzersiz ID kullanın (idempotency key)
  • HMAC imzası ile webhook doğrulama yapın
  • Başarısiz teslimatlar için retry mekanizmesi kurun (exponential backoff)
  • Webhook loglarını saklayın ve izleyin
  • Timeout süreleri belirleyin (temsili: 30 saniye)

Event-Driven Architecture Patterns

Event Sourcing

Durum değişiklikleri olay olarak kaydedilir. Mevcut durum, olayların tekrarindan turetilir. Audit trail ve temporal queries için idealdir.

CQRS (Command Query Responsibility Segregation)

Okuma ve yazma işlemleri ayrı modeller kullanır. Performans optimizasyonu ve ölçeklenebilirlik sağlar.

Sağa Pattern

Dağılmış transaction yönetimi. Mikroservis mimarisinde tutarlılık için kullanılır.


EDI Standartları ve Kullanım Alanları

EDI veri değişimi

EDI, B2B entegrasyonların önemli bir parçasıdır

EDI (Electronic Data Interchange), is ortakları arasında standart formatta elektronik belge degisimini sağlayan sistemdir. Modern API’lerden önce var olan, ancak hala kritik öneme sahip teknoloji.

EDI Standartları

EDIFACT (UN/EDIFACT)

Birlesmiş Milletler tarafından geliştirilen uluslararası standart. Avrupa ve uluslararası ticarette yaygın.

X12 (ANSI ASC X12)

Kuzey Amerika’da yaygın kullanılan standart. ABD perakende ve sağlık sektörunde hakim.

TRADACOMS

Ingiltere perakende sektörunde kullanılan eski standart.

Yaygın EDI Belge Türleri

  • Sipariş (ORDERS / 850): Satın alma siparişi
  • Sipariş Onay (ORDRSP / 855): Sipariş teyidi
  • Sevkiyat Bildirimi (DESADV / 856): ASN (Advanced Shipping Notice)
  • Fatura (INVOIC / 810): Ticari fatura
  • Stok Raporu (INVRPT / 846): Envanter durumu

EDI İ̇letişim Protokolleri

  • AS2 (Applicability Statement 2): HTTP üzerinden güvenli EDI transferi
  • SFTP: Güvenli dosya transferi
  • VAN (Value Added Network): Üçüncü taraf EDI ağları
  • AS4: Web servisleri tabanlı modern alternatif

EDI vs API: Hangisi Ne Zaman?

  • EDI tercih edin: Büyük perakende zincirleri, lojistik firmaları, B2B partnerlerle zorunlu standart
  • API tercih edin: Modern SaaS entegrasyonları, esnek veri ihtiyacı, hızlı geliştirme
  • Hibrit yaklaşim: EDI partnerler için EDI, modern sistemler için API

Sahadan Örnek: Çok Kanallı Perakende Entegrasyonu

Gerçek Vaka (Markasız)

Perakende entegrasyon senaryosu

Durum

45 şubelik perakende zinciri. 8 farklı sistem entegre edilecek: Merkezi ERP, 3 farklı POS markası, e-ticaret platformu, banka POS, e-fatura servisi, lojistik partneri. Günlük işlem hacmi: temsili 15.000+ satış.

Entegrasyon Mimarisi Kararları

  1. Middleware seçimi: iPaaS çözümu seçildi (hazır konektorler, görsel tasarım, yönetilen altyapı)
  2. POS entegrasyonu: Real-time API ile satış anında ERP’ye veri aktarımı
  3. E-ticaret: Webhook ile sipariş bildirimi, batch ile stok senkronizasyonu (15 dakika aralık)
  4. Banka: SOAP API ile mutabakat, günlük batch ile ERP transferi
  5. E-fatura: Real-time API ile fatura oluşturma ve gönderim
  6. Lojistik: EDI (DESADV) ile sevkiyat bildirimi

Sonuç (Temsili)

  • Entegrasyon kurulum süresi: 12 hafta
  • Günlük işlem başarı oranı: %99.7
  • Ortalama veri gecikmesi: POS-ERP 3 saniye, e-ticaret stok 12 dakika
  • Manüel veri girişi azalması: %85
  • Mutabakat süresi: 2 is gününen 2 saate düşürüldü

Entegrasyon Mimarisinde En Sik Yapılan 7 Hata

1. Hata Senaryolarını Planlamamak

“Sistem her zaman çalışır” varsayımı. Hedef sistem kesintisi, ag hatası, timeout durumlarında ne olacağı belirlenmemiş. Veriler kaybolur veya tutarsız kalır.

2. Idempotency Sağlanmamasi

Aynı mesaj birden fazla islendiginde tekrarli kayıt oluşur. Örnegin aynı sipariş iki kez ERP’ye yazılır. Her mesaja benzersiz ID atanmali ve tekrar kontrol edilmeli.

3. Yetersiz Loglama ve Izleme

Entegrasyon hataları ancak kullanıcılar sikayette bulunduğunda fark ediliyor. Proaktif izleme, alarm ve dashboard eksık. Sorun tespiti saatler alıyor.

4. Sikilastirilmis (Tight) Bağımlılık

Sistemler birbirine doğrudan bağımlı. Bir sistemde degisiklik, tüm entegrasyonları etkiliyor. Middleware veya abstraction katmanı olmadan bağlantı kurulması.

5. Güvenlik Ihmal Edilmesi

API anahtarları kod içinde sakli, HTTPS yerine HTTP kullanılır, kimlik doğrulama zayıf. Veri sızıntısı ve yetkisiz erişim riskleri göz ardı edilir.

6. Dokümantasyon Eksikliği

Entegrasyon akisleri, veri eşleme kuralları, hata kodları dokümante edilmemiş. Geliştirici degisimlerinde bilgi kaybı, bakım zorlukları yaşanır.

7. Test Ortamı Olmadan Canlı Geçiş

Entegrasyonlar doğrudan canlı (production) ortamda test ediliyor. Hatalar gerçek verileri etkiliyor, geri alma zor ve maliyetli.

Entegrasyon hata önleme

Dikkatli planlama hataları önler


Hata Yönetimi ve Retry Stratejileri

Entegrasyon sistemlerinde hatalar kacinimazdir. Önemli olan, hataları zararsiz hale getiren mekanizmaları kurmaktir.

Retry (Yeniden Deneme) Stratejileri

1. Sabit Aralık (Fixed Interval)

Her başarısiz denemeden sonra aynı süre beklenir (temsili: 30 saniye). Basit ancak hedef sistemi yorabilir.

2. Exponential Backoff

Her denemede bekleme süresi katlanarak artar (1s, 2s, 4s, 8s…). Hedef sisteme nefes alma alanı verir.

3. Exponential Backoff + Jitter

Bekleme süresine rastgele varyasyon eklenir. Çok sayıda istemcinin aynı anda yeniden denemesini önler.

Circuit Breaker Pattern

Hedef sistem sürekli hata donduruyorsa, istekleri geçici olarak durdurur:

  • Closed (Kapalı): Normal çalışma, istekler geçiriliyor
  • Open (Açık): Hata esigi asildi, istekler engelleniyor
  • Half-Open (Yarı Açık): Test istekleri gönderiliyor, iyileşme kontrol ediliyor

Dead Letter Queue (DLQ)

Tüm retry denemeleri başarısiz olan mesajlar, ayrı bir kuyruğa (DLQ) taşınir. Bu mesajlar:

  • Manüel inceleme için bekletilir
  • Kurtarma (recovery) işlemine tabi tutulur
  • Analiz için saklanır

Idempotency (Tekrar Edilebilirlik)

Aynı işlemin birden fazla kez çalıştirilmesi, sonuçu degistirmemelidir. Nasıl sağlanir?

  • Her mesaja benzersiz ID (UUID) atanır
  • İ̇şlem öncesi ID kontrol edilir
  • Daha önce islenmisse, sonuç doğrudan döndürülür

Izleme (Monitoring) ve Alarm Sistemleri

Entegrasyon sistemleri 7/24 izlenmelidir. Sorunlar kullanıcılardan önce tespit edilmelidir.

Izlenmesi Gereken Metrikler

İ̇şlem Metrikleri

  • Toplam işlem sayısı (dakika/saat/gün bazında)
  • Başarıli/başarısiz işlem oranı
  • Ortalama işlem süresi (latency)
  • Kuyruk derinliği (queue depth)

Sistem Metrikleri

  • CPU, bellek, disk kullanımi
  • Network I/O
  • Bağlantı havuzu (connection pool) durumu

Is Metrikleri

  • İşlenen sipariş/fatura sayısı
  • Veri tutarlılığı oranları
  • SLA uyum oranları

Alarm Stratejisi

  • Kritik (P1): İ̇şlem başarı oranı %95 altına düştü – anında bildirim
  • Yüksek (P2): Latency normalin 2 katı – 15 dakika içinde bildirim
  • Orta (P3): DLQ’da birikmiş mesaj – saatlik özet
  • Düşük (P4): Kapasıte uyarıları – günlük rapor

Dashboard ve Görselleştirme

Entegrasyon sagligi tek bakışta gorulecek dashboard’lar oluşturun:

  • Trafik haritası (hangi sistemler konuşuyor)
  • Hata dağılımı (sistem, tıp, zaman bazında)
  • Trend grafikleri (işlem hacmi, hata oranı)
  • SLA takip tablosu

Entegrasyon Başarı Metrikleri

Aşağıdaki metrikler, entegrasyon mimarisinin sagligini değerlendirmek için kullanılabilir (temsili değerler):

Metrik Hedef Kritik Eşik Ölçüm Yöntemi
İ̇şlem başarı oranı %99.5+ < %95 Başarıli / Toplam işlem
Real-time latency (P95) < 3 saniye > 10 saniye API response time
Batch işleme süresi < 30 dakika > 2 saat Job duration
DLQ mesaj sayısı 0 > 100 Kuyruk derinliği
Veri tutarlılığı oranı %99.9+ < %99 Mutabakat raporu
Sistem uptime %99.9+ < %99 Availability monitoring
Ortalama hata çözüm süresi < 2 saat > 8 saat Incident tracking

Entegrasyon Mimarisi Kontrol Listesi

Sistem entegrasyonu mimarisi tasarımi ve uygulamasında aşağıdaki maddeleri kontrol edin:

A. Mimarı Tasarım

  • Entegrasyon topolojisi belirlendi mi? (Point-to-Point, Hub-Spoke, ESB)
  • Kaynak ve hedef sistemler envantere alındı mi?
  • Veri akış diyagramları çizildi mi?
  • Real-time vs batch kararları verildi mi?
  • Middleware/iPaaS seçimi yapıldı mi?

B. API ve Protokol

  • API türleri belirlendi mi? (REST, SOAP, GraphQL)
  • Veri formatları tanimlandi mi? (JSON, XML, EDI)
  • Kimlik doğrulama yöntemi seçildi mi? (API Key, OAuth)
  • Rate limiting politikası belirlendi mi?
  • API versiyon yönetimi planlanmi?

C. Hata Yönetimi

  • Retry stratejisi tanimlandi mi? (Exponential backoff)
  • Circuit breaker parametreleri belirlendi mi?
  • Dead letter queue kuruldu mu?
  • Idempotency mekanizmesi uygulanmi?
  • Timeout süreleri optimize edildi mi?

D. Güvenlik

  • HTTPS zorunlu kilindi mi?
  • API anahtarları güvenli saklanmi? (Secret manager)
  • Webhook doğrulama (HMAC) uygulanmi?
  • IP whitelist / firewall kuralları tanimlandi mi?
  • Hassas veri maskeleme yapılmi?

E. Izleme ve Operasyon

  • Loglama stratejisi belirlendi mi?
  • Metrik toplama sistemi kuruldu mu?
  • Alarm eşikleri tanimlandi mi?
  • Dashboard oluşturuldu mu?
  • Incident response süreci dokümante edildi mi?

F. Test ve Devreye Alma

  • Test ortamı hazır mi?
  • Entegrasyon testleri yazilmi?
  • Yük (load) testi yapıldı mi?
  • Rollback planı hazır mi?
  • Dokümantasyon tamamlandı mi?

Projenize özel entegrasyon mimarisi tasarımi için iletişim sayfasından ulaşabilirsiniz.


Sikca Sorulan Sorular (SSS)

Sistem entegrasyonu mimarisi, farklı yazılım sistemlerinin (ERP, POS, e-ticaret, banka, e-fatura) birbirleriyle veri alışverişi yapabilmesi için tasarlanan teknik yapıdır. Bu mimarı; API tasarımi, veri formatları, iletişim protokolleri, hata yönetimi ve izleme stratejilerini kapsar.

Real-time entegrasyon, veriyi anında transfer eder (örnegin POS satışi anında ERP’ye yansır). Batch entegrasyon işe verileri belirli aralıklarla toplu olarak aktarır (örnegin günlük stok senkronizasyonu). Real-time anlık veri gerektirir, batch işe sistem yükünü azaltır ve hata toleransı sağlar.

Middleware, farklı sistemler arasında köprü görevi gören yazılım katmanıdır. Veri dönüşümu, protokol cevirisi, kuyruk yönetimi ve hata işleme gibi görevleri üstlenir. Sistemler birbirini doğrudan tanımak zorunda kalmaz, middleware üzerinden haberlesir. Bu yaklaşim bakım kolaylığı ve esneklik sağlar.

Webhook, bir sistemde olay gerçeklestiginde otomatik olarak başka bir sisteme HTTP isteği gönderen mekanizmadir. Örnegin e-ticaret platformunda yeni sipariş geldiğinde ERP’ye bildirim gönderilir. Polling (sürekli sorgulama) yerine event-driven yaklaşim sağlar, kaynak tüketimini azaltır.

Entegrasyon hata yönetimi için: 1) Retry mekanizmesi (belirli aralikla yeniden deneme), 2) Dead letter queue (başarısiz mesajları ayrı kuyruğa alma), 3) Idempotency (aynı işlemin tekrarı sorun yaratmamali), 4) Circuit breaker (hedef sistem cevap vermezse istekleri durdurma), 5) Kapsamlı loglama ve alarm sistemi kullanılmalıdır.

Evet, özellikle büyük perakende zincirleri, lojistik firmaları ve uluslararası ticarette EDI hala yaygın kullanılır. EDIFACT ve X12 standartları ile sipariş, sevkiyat ve fatura verileri değiştirilir. Modern API’lerle birlikte hibrit yaklaşımlar da uygulanmaktadir.


Yazar Hakkında

Koray Çetintaş, dijital dönüşüm, ERP mimarisi, süreç muhendisligi ve stratejik teknoloji liderliği alanlarında uzman danışmandır. Yapay zeka, IoT ekosistemleri ve endüstriyel otomasyon konularında saha deneyimi ile “Strateji + Insan + Teknoloji” yaklaşımını uygular.

Yazar Hakkında

Koray Çetintaş, dijital dönüşüm, ERP mimarisi, süreç mühendisliği ve stratejik teknoloji liderliği alanlarında uzman danışmandır. Yapay zekâ, IoT ekosistemleri ve endüstriyel otomasyon konularında saha deneyimi ile "Strateji + İnsan + Teknoloji" yaklaşımını uygular.

Projeniz İçin Destek Alın

Dijital dönüşüm yolculuğunuzda size rehberlik edebilirim. Ücretsiz ön görüşme için randevu alın.