Dapr ile Dağıtık Uygulamalar Geliştirme

Günümüzde, dağıtık sistemlerin geliştirilmesi giderek artan bir ihtiyaç haline geldi. Ancak sistemlerin karmaşıklığına bağlı olarak bu tür uygulamaları geliştirmek ve yönetmek, biz geliştiriciler için zorlukları da beraberinde getiriyor. Servisler arasındaki iletişim ve state yönetimi gibi konular hiç de kolay değil. Dapr (Distributed Application Runtime) tam da bu noktada devreye giriyor ve biz geliştiricilere yardımcı oluyor.

Dapr, dağıtık uygulamaları daha kolay ve hızlı bir şekilde geliştirmek için tasarlanmış bir platform. Sunduğu özellikler sayesinde, servisler arasındaki iletişimi, state yönetimini, event yayınlama/dinleme gibi işleri daha kolay bir şekilde gerçekleştirebiliyoruz. Hatta aktör programlamayı bile daha kolay halledebiliyoruz.

Actor Model - Microsoft Orleans

OOP dört temel kavram üzerine kuruludur. Bunlar; Encapsulation, Abstraction, Inheritance ve Polymorphism. Bunlar arasından en önemlisi encapsulation'dır. Encapsulation nesnenin internal verisine dışarıdan erişilememesini ifade eder.

Stok özelliğine sahip bir product nesnesi düşünüyoruz. Stoğu düşürmek için "DecreaseStock" metoduna ihtiyacımız olacak. Stoğa dışarıdan müdahale edilemeyecek ve business kurallarına sahip "DecreaseStock" metodu ile stok düşürülecektir. "DecreaseStock" metoduna aynı anda iki veya daha fazla thread girerse ne olur? Ne kadar stok düşeceğini sadece Allah bilir.

Bunun nedeni, nesne yönelimli programlamanın en büyük dezavantajı olan "shared memory" sorunudur. Tabii ki bu sorunu aşmak için birçok yöntem ve yaklaşım var. En klasik yöntem, "locking" mekanizmasıdır, ancak bu oldukça maliyetli bir işlemdir, bu yüzden bundan kaçınmak gerekir. Actor Model, hem locking maliyetinden kurtarır hem de dağıtık bir ortamda dağıtık bir ortamda değilmiş gibi geliştirme yapmamıza imkan verir. Peki bunu nasıl yapar?

Domain Driven Design - Tactical Patterns

DDD, karmaşıklığı yüksek yazılımlar için ortaya atılmış bir yaklaşımdır. Bu yaklaşım, yazılımların geliştirilmesi ve yazılımların sürekliliğinin sağlanması aşamalarındaki karmaşıklıkları basitleştirir. DDD, Strategical ve Tactical olmak üzere ikiye ayrılır. DDD'nin felsefesi de özü de strategical pattern kısmındadır. Fakat bu yazının konusu strategical pattern olmayacak. Tactical pattern, mimari kısım ile ilgilenir. Sınıfların, metotların ve bağımlılıkların nasıl olması gerektiği ile ilgilidir. Yani clean architecture diyebiliriz. O zaman başlayalım.

Test Driven Development

TDD Cycle

TDD, önce test case'in yazılmasını sonrasında kodun yazılmasını söyler.

TDD döngüsel bir süreçtir ve RED, GREEN, REAFTOR olmak üzere üç aşamayı içerir. RED aşamasında test case yazılır ve çalıştırılır. Test başarısız olur. GREEN aşamasında test case'in geçmesi için ilk kod yazılır. Kodun clean olmasına ihtiyaç yoktur. Asıl amaç test case'in geçmesi için en basit kodu yazmaktır. Test case tekrar çalıştırılır. Test başarılı olduysa REFACTOR aşamasına geçilir. Bu aşamada ise kod refactor edilebiliyorsa edilir. Test case tekrar çalıştırılır. Eğer test case başarısız olursa kod tekrar düzenlenir. Bu döngü kod istenen hale gelene kadar devam ettirilir.

Modular Monolith Nedir?

Traditional Monolith

Öncelikle Traditional Monolith yaklaşımından bahsedelim. Bu yaklaşım katmanlara odaklanır. UI, Business ve Data olmak üzere üç katman içerir. Bir projedeki tüm özellikler dikey olarak bu katmanlara ayrılır. Bu üç katman arasında Business katmanı, tüm modüllerin business logic'ini içeren katmandır. Her bir modül, diğer modüllerin business logic'ini bilir ki buna tightly coupled diyebiliriz.

Blockchain Uygulamalarına Mobil Cüzdan ile Bağlanma

Blockchain Uygulama Geliştirme yazı serisinde UI projesinde cüzdan olarak MetaMask'ı kullanmıştık. Uygulamayı kullanmak için tarayıcıda MetaMask'ın eklenti olarak kurulu olması gerekiyordu. MetaMask'ın aynı zamanda mobil uygulaması da var. Cüzdan ile iletişimi tarayıcı eklentisi yerine mobil ile sağlayabilir miyiz? Cevap evet sağlayabiliriz.

ASP.NET Core Time Limited Protection

ASP.NET Core'da verilerimiz için belirli bir süreliğine koruma sağlayabiliriz. Örneğin şifrelediğimiz bir verinin çözülmesi için bir dakikalık bir süre tanımlayabiliriz. Yani bu bir dakikalık süre aşılırsa şifreli verinin çözülemeyeceği anlamına gelir. Bunun için DataProtectionAPI kullanılıyor.

Blockchain Uygulama Geliştirme – #3 Kontratı Yayınlama ve API Hazırlama

Bir önceki yazımızda UI ile etkileşimin nasıl gerçekleştiğini görmüştük. Bu yazımızda kontratımızı Ethereum'un test ağlarından olan Rinkeby'de yayınlayacağız. Sonrasında kontrat için API hazırlayacağız. Eğer önceki yazıyı okumadıysanız aşağıdaki bağlantıdan giderek okuyabilirsiniz.

Blockchain Uygulama Geliştirme – #2 UI ile Etkileşim

Bir önceki yazımızda kontratımızı hazırlamıştık, test kodlarımızı yazmıştık. Bu yazıda ise UI ile kontratın iletişimini gerçekleştireceğiz ve kontratta tanımlı fonksiyonları çağıracağız. Eğer önceki yazıyı okumadıysanız aşağıdaki bağlantıdan giderek okuyabilirsiniz.

Blockchain Uygulama Geliştirme - #1 Kontrat Oluşturma

3 parça olacak bu yazı serisinde Dapp(Decentralized application) denilen merkeziyetsiz bir blockchain uygulaması geliştireceğiz. Hands-on Labs tadında olacak. Uygulama geliştirmeye başlayarak öğrenme yolunu tercih edeceğiz. İlk yazı kontrat oluşturmak üzerine olacak.

Smart Contract ve Solidity

Smart Contract, blockchain ağı üzerinde çalışan içerisinde veriyi de saklı tutan kod parçalarıdır. Yani kodun ve verinin bir olduğu bir yapı. Bu kontratı yazmamızı sağlayan programa dilinin adı ise Solidity. Çok gelişmiş bir değildir ki zaten kontrat yazarken ihtiyaçlarımız da belli.