Oluşturduğumuz yazılım sistemlerinde, kullanıcının sistemden beklentisini ve birleşik sistemler yapısının birbirleriyle olan ihtiyaçlarını anlamak zor olabilir. Bu yazıda iletişim halinde olan sistemler kümesini anlamaya çalışacağız.

İlişik Sistemler: Bir Konuşmanın Anatomisi

Konuya doğrudan yazılımdan başlamak yerine, önce gerçek hayattaki bir durumla eşleştirerek anlamaya çalışalım. Sohbet halinde iki insan düşünelim: Biri bir şeyler anlatır, diğeri ise dinler. Dinleyen bazen başını sallar, bazen gözlerini kısar, bazen de tam anlamasa bile “hmm” deyip geçer. Gerçek iletişim sadece konuşmakla değil, aynı dili konuşmakla da sınırlı değildir; esas olan, aynı anlamı paylaşabilmektir.

Yazılım sistemleri de tıpkı insanlar gibidir. Her biri kendi görevini yerine getirir, ancak diğer sistemlerle ilişki kurmak zorundadır. Örneğin bir sipariş sistemi, bir kargo sistemiyle etkileşim kurmadan var olabilir mi? Ya da bir kullanıcı verisi, etrafında şekillenen hizmetler olmadan gerçekten anlam kazanabilir mi?

Bağlılık ve Bağlı Kalma: Sağlıklı İlişkiler Kurmak

İnsanlar arası ilişkilerde “bağımlılık” genellikle sağlıksız bir durumu ifade eder. Yazılım sistemlerinde de bu geçerlidir. Bir modül diğerine sıkı sıkıya bağlıysa, o değiştiğinde, diğeri de kırılır. Ama tamamen kopuk olmak da mümkün değildir. Önemli olan "bağlı ama bağımlı değil" olarak kalmaktır.

• Teknik karşılık: Bir mikroservis başka bir mikroservisin veritabanına doğrudan erişmek yerine, bir API veya mesajlaşma sistemi aracılığıyla iletişim kurar. Bu, gevşek bağlılık (loose coupling) sağlar ve sistemler birbirinden bağımsız olarak gelişebilir.

Anlamlı İletişim: Duyulmak mı, Anlaşılmak mı?

İki kişi aynı dili konuşuyor olabilir ama aynı şeyi mi kastediyorlar? Yazılımda da bu geçerlidir. Sistemler yalnızca veri alışverişi yapmaz. O verilerin bağlamı, türü, ne zaman gönderildiği, ne amaçla gönderildiği çok önemlidir.

• İnsani karşılık: Birine “iyi misin?” diye sormakla gerçekten iyi olup olmadığını anlamak farklı şeylerdir. İletişimde her iki taraf da sorulan bir sorudan farklı anlamlar çıkarabilir.
• Teknik karşılık: Bir servis, bir diğerine "OrderCreated" olayını gönderdiğinde, bu olayın alıcı tarafça doğru yorumlanması gerekir. Stok servisi için bu olay "stoğu düş", kargo servisi için "kargoyu hazırla" anlamına gelebilir. Her servis, olayı kendi bağlamında değerlendirir.

Empati ile Sistem Tasarımı

Belki de yazılımda ilişkisel sistemleri tasarlarken gözden kaçan en önemli unsur empatidir. Empati, diğer sistemin ihtiyaçlarını, sınırlamalarını ve yükünü öncesinden hesaplayıp, düşünüp buna göre tasarlanmasını gerektirir.

• İnsani karşılık: İyi bir arkadaş, senin anlatmadıklarını da sezer. Bir bakıştan ne hissettiğini çıkarabilir ve buna göre seninle iletişim kurar. Kendini senin yerine koyarak, her detayı senin yerine düşünebilir.
• Teknik karşılık: İyi tasarlanan bir sistem, veri göndereceği zaman alıcının hızını, kapasitesini, format beklentisini göz önünde bulundurur. Bu, sadece teknik değil, mimari bir nezakettir. İhmal edildiğinde veya umursanmadığında iki sistem de sağlıklı çalışmaz; Biri alınan veri hızına yetişemezken diğer sistemin veri göndermeye devam etmesi, bu sistemlerin üretim amacının dışına çıkmasına neden olur ve hizmet alan bir kullanıcı için artık anlamı yoktur.

^{İnsan iletişimi ve yazılım algoritmalarının bir arada gösterildiği temsili bir görsel. (Yapay zeka ile oluşturulmuştur.)}

Yazılım Mimarisine İnsani Bir Bakış

Yazılım sistemleri, makineler arası iletişimden fazlasıdır. Onlar, insan tarafından tasarlanan, insan için çalışan, insan gibi düşünen yapılardır. Sağlıklı ilişkiler kurmak, anlamlı mesajlar göndermek ve empatiyle tasarlamak, hem yazılımın ömrünü uzatır hem de geliştiricinin ruhunu besler. İlişkisel sistemleri anlamak, sadece daha iyi kod yazmak değil; daha iyi ilişkiler kurmayı da öğrenmektir.

Şimdi de bu anlatılanları farklı ilişkisel sistem düzeylerinde teknik olarak yorumlayalım.

1. Mikroservisler Arası İlişki

Senaryo: Bir e-ticaret sisteminde üç servis olduğunu düşün:

• Sipariş Servisi
• Stok Servisi
• Kargo Servisi

Bağlılık (Coupling):

• Sipariş servisi doğrudan Stok servisinin veritabanına erişmemeli. Bunun yerine, bir API çağrısı ya da mesaj kuyruğu (message queue) ile iletişim kurmalı.
• Bu, gevşek bağlılık (loose coupling) sağlar.

Haberleşme (Communication):

• Sipariş verildiğinde, Sipariş Servisi bir OrderCreated olayı yayınlar.
• Stok Servisi bu olayı dinler ve stoktan düşer.
• Kargo Servisi de aynı olayı dinleyerek kargo hazırlığını başlatır.

Anlamlandırma (Semantics):

• Tüm servisler olayları kendi bağlamlarında anlamlandırmalı.
• Örneğin OrderCreated olayı:
• Stok Servisi için: "Bu ürünlerden düşmeliyim"
• Kargo Servisi için: "Bu adres için kargo hazırlamalıyım"

Bu, semantic interoperability örneğidir.

2. Modüler Monolith Yapısında Modüller Arası İlişki

Senaryo: Aynı kod tabanı içinde ayrı modüller var:

• Kullanıcı, Ürün, Sipariş

Bağlılık:

• Sipariş modülü Kullanıcı modülüne bağımlı ama interface ile.
• UserService interface’i üzerinden iletişim kurar, böylece uygulama içi bağımlılıklar kontrol altında olur.

Haberleşme:

• Sipariş modülü bir sipariş oluşturduğunda, Kullanıcı modülüne “bu siparişin sahibi kim?” diye sorar.

Anlamlandırma:

• Kullanıcı modülü aktif kullanıcıyı belirlerken başka modüllerin verilerini (ör. sipariş geçmişi) kullanmaz. Kendi anlamını kendi üretir.

3. Veritabanı Düzeyinde İlişki

Senaryo: users ve posts tabloları var.

Bağlılık:

• posts.user_id dış anahtar (foreign key) olarak users.id’ye bağlıdır.

Haberleşme:

• SQL JOIN işlemleriyle veri birleştirilir.

Anlamlandırma:

• Veritabanı ilişkileri verinin anlamsal bağını doğrudan tanımlar:
• “Bir post, bir kullanıcıya aittir.”

4. API Tabanlı Sistemler

Senaryo: Bir frontend uygulaması ve bir backend API.

Bağlılık:

• Frontend, backend API'nin sözleşmesine (contract) bağlıdır. API değişirse, frontend de etkilenir.

Haberleşme:

• HTTP üzerinden JSON verileri gönderilir/alınır.

Anlamlandırma:

• API dökümanları (Swagger gibi) ile frontend, backend’in döndürdüğü verinin anlamını bilir.
• status: "shipped" -> Bu ürün kargoya verilmiştir.

5. Event-Driven Architecture (EDA)

Senaryo: Bankacılık sistemi

• TransactionCreated olayı
• FraudDetection, Notification, Analytics servisleri

Bağlılık:

• Yayıncı servis, olayın kim tarafından dinleneceğini bilmez.

Haberleşme:

• Mesaj kuyruğu (Kafka, RabbitMQ)

Anlamlandırma:

• Her servis, olayın kendisi için ne anlama geldiğini kendi bağlamında bilir.
• TransactionCreated olayı:
• Fraud servisi: Şüpheli işlem var mı?
• Notification: Kullanıcıya SMS gönder.
• Analytics: Toplam işlem hacmini güncelle.

Yazılımda ilişkisel sistemleri anlamak, sadece sistemlerin nasıl bağlandığını değil, bu bağlantıların nasıl anlam taşıdığını da anlamakla olur. Gevşek bağlılık, iyi tanımlanmış arayüzler, olay temelli düşünme ve anlam birlikteliği, sürdürülebilir ve genişletilebilir sistemlerin temel taşlarıdır.

Okuduğunuz için teşekkürler.