Mikroservis mimarisinin başarısızlık sebeplerinin yaklaşık yüzde 70'i yanlış servis sınırı tanımından kaynaklanıyor. Bu rehberde domain-driven bounded context yaklaşımıyla servis sınırlarını nasıl çizeceğinizi ve servisler arası iletişimi nasıl tasarlayacağınızı adım adım anlatacağım. Adım 1: Bounded Context Belirleme. İlk yapılması gereken iş, domain'i analiz edip subdomain'leri çıkarmak. Bir e-ticaret örneğinde Catalog, Cart, Order, Payment, Shipping ayrı bounded context'lerdir. Her birinin kendi ubiquitous language'i ve veri modeli olmalı. "Product" kelimesi Catalog'da farklı, Order'da farklı şey ifade eder. Bu nüansı görmezseniz, servisleriniz aslında dağıtık bir monolit olur. Adım 2: Veri Sahipliği. Her servis kendi veritabanına sahip olmalı. Shared database antipattern'i, mikroservis avantajlarını sıfırlar. Veri çoğaltma kaçınılmazdır. Catalog'daki ürün adı, Order servisinde de tutulur ama eventual consistency ile senkronize edilir. Burada CAP teoremi devreye giriyor: availability mi consistency mi tercih edeceğinizi domain gereksinimi belirler. Adım 3: İletişim Pattern Seçimi. Synchronous REST veya gRPC, basit request-response için uygun ama coupling yaratır. Asynchronous messaging, event-driven mimarinin temelidir ve servisleri zaman olarak decouple eder. Pratik kural: query'ler synchronous, command'lar ve domain event'ler asynchronous olsun. Adım 4: Saga Pattern ile Distributed Transaction. Tek bir iş akışı birden fazla servisi etkiliyorsa (örnek: sipariş oluşturma, ödeme, stok düşme), iki yaklaşım var: choreography (her servis kendi event'ini yayar, diğerleri reaksiyon verir) ve orchestration (merkezi bir orchestrator akışı yönetir). Choreography daha decoupled ama debug zor, orchestration daha kontrollü ama coupling artar. Adım 5: API Gateway ve BFF. Frontend'in onlarca servise direkt çağrı yapması anti-pattern'dir. API Gateway, authentication, rate limiting, request aggregation görevlerini üstlenir. Birden fazla istemci tipiniz varsa (web, mobile, partner), Backend-for-Frontend pattern'iyle her istemci için ayrı gateway tasarlayın. Adım 6: Observability. Mikroservislerde tek bir request 10 servisten geçebilir. Distributed tracing (OpenTelemetry standardı), her span'i takip etmenizi sağlar. Centralized logging ve metrics olmadan production'da debug imkânsızdır. Bu üçü olmadan canlıya çıkmayın. Adım 7: Failure Tolerance. Circuit breaker, retry with backoff, timeout, bulkhead pattern'lerini her synchronous çağrıya uygulayın. Bir downstream servisin yavaşlaması, upstream'inizi de yavaşlatmamalı. Son olarak: mikroservis kararı bir araç tercihi değil organizasyonel bir karardır. Conway yasası gerçektir, takım yapınız mimariyi belirler. Küçük takımsanız önce modüler monolit yapın, sınırlar olgunlaştıkça parçalayın.