"Enter"a basıp içeriğe geçin

Kategori: Web Uygulamaları

Test Driven Development

TDD Workshop

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.

Traditional Monolith

ASP.NET Core Feature Management

Feature Management, .NET Core uygulamalarında özellik yönetimi sağlar. Uygulamaya ait özelliklerin aktiflik/pasiflik durumunun yönetilmesine ve sorgulanmasına imkan verir. Örneğin yeni geliştirdiğiniz bir özelliğin belirli tarih aralığında aktif olmasını sağlayabilirsiniz. Başka bir örnek vermek gerekirse geliştirdiğiniz bir özelliğin belirli yüzdelik oranla aktif olmasını sağlayabilirsiniz. A/B testi gibi.

ASP.NET Core ile Event Sourcing – 02 Messaging

1. Giriş

Bu yazı aşağıdaki yazının devamı niteliğinde olduğu için aşağıdaki yazıyı okuyup uygulamanızı öneririm. Aşağıdaki yazıdaki örnek proje üzerinden devam edeceğiz.

Bir önceki yazıda Kanban Board örneği yapmıştık. RESTful API oluşturarak create, assign, move ve complete endpoint‘lerini yazmıştık. Bu endpoint‘lere gelen istekleri birer event olarak Event Store’a kaydetmiştik. Yani Event Store’un store kısmı ile ilgilenmiştik. Bu yazıda ise messaging kısmı ile ilgileneceğiz.

RESTful API endpoint‘lerimize aşağıdaki endpoint‘i de dahil edeceğiz.

[GET] api/tasks/{id}

ASP.NET Core ile Event Sourcing – 01 Store

1. Giriş

Bu örneği uygulamadan önce aşağıdaki yazıyı okumanızı öneririm.

Yukarıda belirttiğim yazıda aşağıdaki gibi cümle kurmuştum.

Event Sourcing için .NET dünyasında Event Store adında bir teknoloji var. Bu teknoloji “Aggregate” ve “Projection” için çözüm sunmaktadır. Yani event‘leri kaydedebileceğimiz store’u sağlamakla birlikte “Query” veritabanlarına kayıt atabilmemiz için gerekli olan “Messaging” ve “Projection” hizmetini de sağlamaktadır.

Bu yazıda Event Store’un store kısmı ile ilgileneceğiz. Yani event‘leri kaydedebileceğimiz veritabanı özelliği ile ilgileneceğiz. Sonraki yazımda ise messaging kısmı ile ilgileneceğiz.

Örnek uygulama olarak klasik Kanban Board örneğini seçtim.

RESTful API endpoint’lerimiz aşağıdaki gibi olacak.

[POST] api/tasks/{id}/create
[PATCH] api/tasks/{id}/assign
[PATCH] api/tasks/{id}/move
[PATCH] api/tasks/{id}/complete

ASP.NET Core ile Couchbase GeoSearch

Bu yazının konusu Couchbase kullanarak “GeoSearch” işleminin nasıl yapılacağı olacak.

1. Couchbase Kurulumu

Bunun için aşağıdaki komutu çalıştırarak docker ile Couchbase ayağa kaldırıyoruz.

docker run -d --name couchbase -p 8091-8094:8091-8094 -p 11210:11210 couchbase

Couchbase ayağa kalktığında aşağıdaki adresten yayın yapmaya başlayacaktır.

http://localhost:8091/

“Setup New Cluster” butonuna tıklayarak cluster oluşturuyoruz. Parolayı “123456” tanımlıyoruz.

Create New Cluster
Create New Cluster

“Configure Disk, Memory, Services” butonuna tıklayarak cluster konfigürasyonuna geçiyoruz. Couchbase için memory ayırmamız gerekli. Mevcut memory durumunuza göre ayarlama yapabilirsiniz. “Analytics”i kapatabilirsiniz. “Save & Finish” butonuna tıklayarak cluster kurulumunu tamamlıyoruz.

Event Sourcing Neydi?

Önceden servislerimiz aşağıdaki gibi olurdu.

Application Services 01

Bu servisimiz yüzlerce satır koddan oluşurdu. Bu karmaşadan kurtulmak için CQRS ile servislerimizi “Command” ve “Query” olmak üzere ikiye böldük. CRUD işlemlerimizi “Command” servisleri ile, sorgulama işlemlerimizi “Query” servisleri ile yaptık. Ortaya aşağıdaki gibi iki ayrı servis çıktı.