.NET backend'lerinin çoğu sonunda aynı düzine şeye ihtiyaç duyuyor: validation, distributed lock, audit\nkaydı, outbox, şifreli kolonlar, tipli ID'ler, idempotent endpoint'ler, rate limit, retry. Her ekip bunları\nyeniden yazıyor; her seferinde biraz farklı, her biri kendince biraz hatalı.
\nOrion ailesi buna benim cevabım: bu problemlerin her biri için küçük, odaklı, tek bir kalite çıtasıyla\nyazılmış ve NuGet'te yayınlanmış kütüphaneler.
\nBugün 89 paket altında 24 kütüphane var ve 350 binden fazla kez indirildiler. Bu yazı neden var\nolduklarını, onları neyin bir arada tuttuğunu ve her birinin ne işe yaradığını anlatıyor.
\nHer Orion kütüphanesi tek bir problemi çözüyor ve kendi başına kullanılabiliyor. OrionLock'u bir lock'a\nihtiyacınız olduğu için eklersiniz, bir platforma üye olduğunuz için değil. Aralarında derin bir bağımlılık\nağı yok; sadece ihtiyacınız olanı alırsınız.
\nBu, bazen \"hayır\" demek anlamına da geliyor. OrionPatch bir transactional outbox; dokümanı saga'ların\nkapsam dışında olduğunu açıkça söylüyor: bir process manager'a ihtiyacınız varsa MassTransit ya da\nWolverine'e bakın. Nerede durduğunu bilen bir kütüphaneye, her şey olmak isteyen bir kütüphaneden daha\nkolay güvenilir.
\nKütüphaneleri birbiri ardına yazarken beş şeyin tekrar tekrar yazıldığını ve her seferinde birbirinden\nuzaklaştığını fark ettim:
\nBunlar artık tek bir yerde, Orion.Abstractions içinde yaşıyor. Yüzeyi 1.0'da donduruldu: bütün\nsözleşmeler 1.x boyunca kaynak ve binary olarak uyumlu kalıyor; bir kütüphane, kardeşinin güncellemesiyle\nkırılmıyor. Bunlara eşlik eden kurallar yazılı ve ailedeki her paket için geçerli.
Bu omurgadan iki kütüphane doğdu. OrionClock bir TimeProvider; onu kabul eden her .NET API'sine\ndoğrudan takılıyor ve testlerin beklemek yerine zamanı ileri sarmasını sağlıyor. OrionResult beklenen\nhatalara bir şekil veriyor: sıfır allocation'lı bir Result<T>, bir Option<T> ve kodu, türü ve alan\nhataları olan yapılandırılmış bir Error.
Girdi ve domain
\nVeri
\nOFFSET bir tablo taraması.Mesajlaşma ve tutarlılık
\nSaveChanges transaction'ı\niçinde kuyruğa al, en az bir kez gönder; karşı tarafta her mesajın etkisini tam bir kez uygula.Koordinasyon
\nHTTP ve API'ler
\n{ data, meta }, hatada RFC\n9457 problem details.Her yerde işe yarayanlar
\nPaket sayfaları kütüphaneleri tek tek gösteriyor. OrionShowcase ise birlikte nasıl çalıştıklarını\ngösteriyor: tek bir para transferinin OrionGuard'ın validation'ından, OrionLock'un distributed lock'larından,\nOrionAudit'in değişiklik kaydından, OrionPatch'in outbox'ından, OrionKey'in tipli ID'lerinden ve OrionVault'un\nşifreli kişisel verilerinden geçtiği, production'a benzeyen bir bankacılık örneği. Bu bütünü kurmak, tek bir\npaketin göründüğünden çok daha zor; örneğin bütün amacı bu.
\nBunları ihtiyacım olduğu için yazdım; yayınlıyorum ki kimse onları yeniden yazmak zorunda kalmasın. Her\nkütüphane MIT lisanslı, dokümantasyonu bu sitede ve issue'lar GitHub'da açık. Veritabanı ya da mesaj\nkuyruğu gerektirmeyenleri doğrudan buradaki playground'da deneyebilirsiniz.
\nBirini kullanıyorsanız ya da denediniz ve işinize yaramadıysa, nedenini bilmek isterim. Birinin bana\nsöyleyebileceği en faydalı şey bu.
", "url": "https://tunahanaliozturk.dev/tr/blog/the-orion-family", "title": "Orion ailesini neden yaptım", "summary": ".NET backend'lerinin çoğu sonunda aynı düzine şeye ihtiyaç duyuyor: validation, distributed lock, audit", "date_modified": "2026-09-30T00:00:00.000Z", "author": { "name": "Tunahan Ali Öztürk", "url": "https://github.com/tunahanaliozturk" }, "tags": [ "dotnet", "orion", "open-source" ] }, { "id": "https://tunahanaliozturk.dev/tr/blog/why-i-built-derbent", "content_html": "Aynı repolarda birden fazla coding agent kullanıyorum. Claude Code bir işi yaparken Codex başka bir işi\nyapıyor, arada Copilot CLI'a bir şey soruyorum. Hepsi işini iyi yapıyor ama hiçbiri diğerlerinin ne\nyaptığını bilmiyor.
\nClaude Code'un bir saat önce \"bu tablo neden böyle\" diye öğrendiğini Codex bilmiyor. Hangi agent'ın hangi\nkomutu çalıştırdığının tek bir kaydı yok. Her CLI'ın kendi MCP server listesi var; GitHub'ı dört kez\nbağlıyorum. Bir agent'ın git push'tan önce bana sormasını istesem, bunu dört ayrı yerde dört ayrı\nbiçimde ayarlamam gerekiyor.
Derbent bu dağınıklığı toplamak için yazdığım, ücretsiz ve açık kaynak bir araç.
\nDerbent, coding agent'larla araçları arasında duran bir kapı. Claude Code, Codex, GitHub Copilot CLI ve\nAntigravity CLI ona sıradan bir MCP server olarak bağlanıyor; sizin MCP server'larınız onun arkasına\ngeçiyor. Her tool çağrısı kapıdan geçiyor ve kapıda dört şey oluyor.
\nOrtak hafıza. Agent'ların memory_write, memory_search ve memory_read araçları var. Bir agent'ın\nbir repoda yazdığı notu, aynı repoda çalışan başka bir agent bulabiliyor. Arama tam metin; bir git\nworktree'si eklendiği repoyla aynı hafızayı paylaşıyor.
Kurallar. Agent, tool ve argümana göre izin ver, reddet ya da sor. Kurallar sırayla deneniyor, ilk\neşleşen kazanıyor. Bir agent'ın kullanamayacağı tool ona hiç listelenmiyor; ismini bilip çağırsa da\nreddediliyor.
\nOnay. \"Sor\" kuralına takılan çağrı siz karar verene kadar bekliyor. Ayrı bir terminalde derbent\nçalıştırınca bekleyen çağrılar en üstte: bir kez onaylarsınız, o agent'ın oturumunun geri kalanı için\nonaylarsınız ya da reddedersiniz. Aynısı herhangi bir shell'den derbent approve 12 ile de oluyor. Kimse\ncevap vermezse süre dolunca çağrı reddediliyor ve agent'a nedeni söyleniyor.
Makbuz. Kapıdan geçen her çağrı bir makbuz bırakıyor: hangi agent, hangi tool, hangi argümanlar, ne\nkarar verildi, sonuç ne oldu. Makbuzlar bir hash zinciri oluşturuyor; derbent verify bir kaydın\ndeğiştirilip değiştirilmediğini ya da silinip silinmediğini söylüyor. Secret'lar kaydedilmeden önce\nmaskeleniyor.
Agent'ların kendi araçları, yani shell komutları ve dosya düzenlemeleri, MCP'den geçmiyor. Ama dört CLI'ın\nda her tool çağrısından önce sizin belirlediğiniz bir komutu çalıştırabildiği bir hook mekanizması var. O\nkomutu derbent gate yapınca bir git push da aynı kurallardan, aynı onaydan ve aynı makbuz zincirinden\ngeçiyor.
Türk tarihinde derbent, dağ geçitlerindeki ve tehlikeli yollardaki muhafızlı karakollardı. Buraları bekleyen\nderbentçiler geçidin güvenliğinden sorumluydu, karşılığında bazı vergilerden muaf tutulurlardı.\nGeçitten kimin geçeceğine karar verir, geçenleri kayda geçirirlerdi.
\nDenediğim her İngilizce kelime (gatekeeper, warden, checkpoint, bastion) ya başka bir güvenlik ürününün\nadıydı ya da fazla genel kalıyordu. Derbent hem yaptığı işi birebir anlatıyor hem de kimsenin kullanmadığı\nbir isim.
\nEn önemli karar: daemon yok. Akla ilk gelen şekil, bütün agent'ların bağlandığı merkezi bir süreç. Ama o\nmerkez her agent'tan önce başlatılmak, ayakta tutulmak, çökünce yeniden başlatılmak zorunda; dinlediği\nport da ayrıca korunmalı. Derbent'te her agent oturumu kendi kapı sürecini başlatıyor ve hepsi aynı SQLite\ndosyasını açıyor. Önceden çalışması gereken hiçbir şey yok, açık port yok, bir süreç çökerse sadece o\nagent'ın kapısı düşüyor.
\nBunun bir bedeli var ve dokümanda açıkça yazıyor: her agent oturumu kapının arkasındaki server'ların kendi\nkopyasını başlatıyor, onaylar da anında değil yoklamayla fark ediliyor.
\nGo ile yazıldı. Claude Code her tool çağrısında derbent gate sürecini yeniden başlatıyor; yani her shell\nkomutu bir sürecin açılıp karar verip kapanmasını bekliyor. Go binary'si bir yorumlayıcı yüklemeden\nbaşlıyor; Windows, macOS ve Linux için tek bir dosya ve makinede başka hiçbir şey istemiyor.
Derbent'in yapmadıklarını yazmak, yaptıklarını yazmak kadar önemliydi.
\nderbent approve\nkomutunu kendisi çalıştırabilir ya da veritabanına yazabilir. Onaylar hatalara ve MCP içinde kalan\nprompt injection'a karşı koruyor.git push* kuralı cd repo && git push komutunu yakalamaz.Bir güvenlik aracının yapabileceği en kötü şey, olduğundan fazlasını vaat etmek. Sınırlarını bilerek\nkullanılan Derbent çok işe yarar; sınırları bilinmeden güvenilen Derbent zarar verir.
\ngo install github.com/tunahanaliozturk/derbent/cmd/derbent@latest
claude mcp add derbent -- derbent mcp --agent claude
codex mcp add derbent -- derbent mcp --agent codex
Bu kadarıyla iki agent aynı hafızayı paylaşmaya başlıyor ve her çağrı kayda geçiyor. Kurallar, onaylar ve\nhook'lar için dokümantasyona bakabilirsiniz.
\nBirden fazla coding agent kullanıyorsanız fikrinizi çok isterim; özellikle hangi çağrıların onaya düşmesini\nistediğinizi merak ediyorum. Issue'lar ve fikirler için GitHub.
", "url": "https://tunahanaliozturk.dev/tr/blog/why-i-built-derbent", "title": "Derbent'i neden yaptım", "summary": "Aynı repolarda birden fazla coding agent kullanıyorum. Claude Code bir işi yaparken Codex başka bir işi", "date_modified": "2026-09-29T00:00:00.000Z", "author": { "name": "Tunahan Ali Öztürk", "url": "https://github.com/tunahanaliozturk" }, "tags": [ "derbent", "ai-agents", "mcp" ] } ] }