Servis sınırlarını çizmek: bounded context'ten veri sahipliğine

Servis sınırı neden mikroservislerin en zor kararıdır?

Mikroservis mimarisinde teknoloji seçimleri sonradan değiştirilebilir; servis sınırları ise değiştirilmesi en pahalı kararlardır. Sınır yanlış çizildiğinde bir iş değişikliği birçok servise dokunur, servisler birbirini sürekli çağırır, ekipler her değişiklikte birbirini bekler ve sonunda dağıtık bir monolit ortaya çıkar: monolitin tüm bağımlılıkları ve ağın tüm maliyetleri birlikte gelir.

İyi bir servis sınırı, bir iş yeteneğinin büyük bölümünü kendi içinde tamamlayan, kendi verisine sahip olan ve değişim nedenleri diğerlerinden ayrışan bir birim çizer. Sınırı belirlerken teknik katmanlara (arayüz servisi, iş mantığı servisi, veri servisi) göre değil, iş alanına göre bölmek gerekir. Katmanlara göre bölünmüş sistemlerde her yeni özellik tüm katmanlara dokunur.

Bu nedenle sınırları çizmeden önce teknolojiyi değil, iş alanını anlamak gerekir: hangi süreçler var, hangi kavramlar hangi bağlamda ne anlama geliyor, hangi ekip hangi kararı veriyor.

Bounded context ile iş alanını bölmek

Domain-Driven Design yaklaşımındaki sınırlı bağlam (bounded context), bir modelin ve dilin geçerli olduğu sınırdır. Aynı sözcük farklı bağlamlarda farklı anlam taşır. Örneğin "müşteri" satış bağlamında potansiyel alıcıdır, faturalama bağlamında vergi bilgisi olan bir tüzel kişidir, destek bağlamında açık talebi olan kişidir. Hepsini tek bir "Müşteri" modeline sığdırmak, her ekibin diğerinin değişikliğinden etkilendiği şişkin bir model üretir.

Sınır belirlemenin pratik adımları: • İş uzmanlarıyla ortak dil çalışması yapın; aynı terimin farklı anlamlarını not edin. Anlam değiştiği yer, sınır adayıdır. • Olay fırtınası (event storming) atölyesiyle iş olaylarını (sipariş verildi, ödeme alındı, kargo yola çıktı) zaman çizgisinde dizin. Olay kümeleri ve aralarındaki ani el değiştirmeler bağlam sınırlarını gösterir. • Her aday bağlam için sahip olduğu veriyi, aldığı kararları ve dışarıya sunduğu davranışları listeleyin. • Bağlamlar arası ilişkileri haritalayın: hangi bağlam hangisine veri ya da olay veriyor, hangisi hangisine bağımlı?

Bir bağlam her zaman tek servise denk gelmek zorunda değildir; ama bir servis birden fazla bağlamı birlikte taşıyorsa sınır ihlali ihtimali yüksektir. Başlangıçta daha büyük, kaba taneli servislerle başlamak ve ihtiyaç ortaya çıktıkça bölmek daha güvenlidir.

Sınırı değerlendirme ölçütleri

Aday sınırları aşağıdaki sorularla test edin:

• Değişim nedeni: Tek bir iş değişikliği çoğunlukla tek servise mi dokunuyor? Her değişiklikte birden fazla servis güncelleniyorsa sınır yanlış olabilir.
• Veri sahipliği: Her veri parçasının tek bir sahibi var mı? Servislerin aynı tabloya yazması kötü işarettir.
• Bağımsız dağıtım: Servis diğerlerini beklemeden yayına alınabiliyor mu?
• Çağrı yoğunluğu: Servisler her istekte birbirini çağırıyorsa ya da birbirinden ayrı iş göremiyorsa birleştirmeyi düşünün.
• Ekip sahipliği: Servisin bir ekibi sorumlu ve o ekip servisi bağımsız yönetebiliyor mu? Mimari ile ekip yapısı birbirini yansıtma eğilimindedir; sınırı çizerken ekip yapısını da gündeme alın.
• Tutarlılık ihtiyacı: Birlikte değişmesi şart olan veriler aynı serviste mi? Aksi hâlde dağıtık işlem sorunu doğar ve saga gibi karmaşık çözümler gerekir.
• Ölçek ve güvenlik farkı: Farklı ölçek, erişim ya da uyumluluk gereksinimi olan parçalar ayrı servis adayıdır.

Örneğin e-ticaret sisteminde katalog, sepet, sipariş, ödeme ve stok ayrı bağlam adaylarıdır. Ancak sepet ile sipariş sıkı bağlıysa ve ekip aynıysa başlangıçta birlikte durmak daha sağlıklı olabilir.

Örnek: yanlış sınırdan doğru sınıra

Örneğin bir kurum, her tablo için bir servis üreterek başlıyor: Müşteri servisi, Adres servisi, Ürün servisi, Fiyat servisi. Bir sipariş oluşturmak için bu servislerin hepsinin çağrılması gerekiyor; fiyat kuralı değiştiğinde hem Ürün hem Fiyat servisi güncelleniyor. Bu, varlık (tablo) bazlı bölmenin klasik hatasıdır: servisler iş yeteneğini değil, veri yapısını yansıtır.

Daha iyi yaklaşım iş yeteneğine göre bölmektir: Katalog (ürün bilgisi ve fiyat politikası), Sipariş (sipariş yaşam döngüsü), Faturalama (vergi ve belge), Müşteri İlişkileri (iletişim ve tercihler). Adres bilgisi hem Faturalama hem Sevkiyat tarafından kullanılır ama anlamı farklıdır; her bağlam kendi adres kaydını tutar ve gerekirse müşteri bilgisini olaylarla günceller.

Geçişte şu sıralamayı izleyin: önce alanı modelleyin, sonra sınır adaylarını belirleyin, sonra sınırı monolit içinde modül sınırı olarak uygulayın ve bağımlılıkları azaltın, ancak sonra ayrı servise çıkarın. Modüler monolit aşaması, yanlış sınırı ucuz yoldan keşfetmenin yoludur.

Veri sahipliği ve bağlam arası ilişkiler

Servis sınırının en somut göstergesi veridir. Her servis kendi verisinin tek sahibidir; diğer servisler bu veriye doğrudan veritabanı üzerinden değil, servisin arayüzü ya da yayımladığı olaylar üzerinden erişir. Bir servisin başka servisin tablosunu okuması sınırı sessizce kaldırır.

Başka servisin verisine ihtiyaç duyulduğunda şu yollar vardır: gerektiğinde senkron çağrı yapmak ya da gerekli veriyi olaylarla alıp yerel bir kopyada tutmak. Olaylarla kopya tutmak servisleri birbirinden bağımsız çalışır kılar ama verinin geçici olarak eski kalabileceğini kabul etmeyi gerektirir. Kopyada yalnızca o bağlamın ihtiyaç duyduğu alanları tutun.

Bağlamlar arası raporlama ihtiyacı için servislerin veritabanlarını birleştirmeyin; ayrı bir raporlama modeli ya da veri ambarı kurun. İş kuralları birden fazla servise bölünmüşse tutarlılığı olaylar, saga ya da yönetici servis gibi desenlerle ele alın ve bu karmaşıklığın bedelini sınır tasarımına geri bildirin.

Sık yapılan hatalar ve sınırı gözden geçirme

Sık yapılan hatalar: tablo bazlı ya da katman bazlı bölmek, çok erken ve çok küçük servisler üretmek, ortak veritabanı paylaşmak, paylaşılan bir "ortak kütüphane" ile iş mantığı bağlamak, ekip yapısını hesaba katmamak, iş uzmanını sürece katmamak, sınırı bir kez çizip bir daha gözden geçirmemek.

Sınır kararları kesin değildir. Zamanla öğrenilen iş bilgisi, sınırın yanlış olduğunu gösterebilir. Şu işaretler yeniden değerlendirme gerektirir: her özellik birden fazla ekibin koordinasyonunu istiyor, bir servis sürekli şişiyor, servisler her zaman birlikte dağıtılıyor, çağrı gecikmesi büyük ölçüde servis çağrılarından geliyor. Sınırı ayarlamak (servisleri birleştirmek ya da bölmek) normal bir mimari bakım işidir.

Kararları belgelemek için her servisin sorumluluğunu, sahip olduğu veriyi, sunduğu arayüz ve olayları kısa bir bağlam kartında toplayın. Bu kart yeni ekip üyelerine sınırı anlatır ve sınır ihlallerini görünür kılar.

Bu beceriyi geliştirmek için eğitim bağlamı

Servis sınırlarını çizmek hem teknik hem iş alanı becerisidir; mimari, ürün ve iş birimlerinin birlikte çalışmasını gerektirir.

Mindset'in Mikroservis Mimarisi eğitimi, servis sınırlarını çizmeyi ilk modüllerinden biri olarak işler; ardından servisler arası iletişim, veri yönetimi ve tutarlılık, dayanıklılık, API geçidi ve servis ağı, gözlemlenebilirlik ile güvenlik modülleri gelir. Bu içerik, monolitten geçişi planlayan yazılım mimarları, kıdemli geliştiriciler ve teknik liderler için uygundur; kurumsal ekiplerde ortak bir sınır belirleme dili kurmak için kullanılabilir.