Büyük Ölçekli Sistem Mimarisi İçin Kapsamlı Rehber: Domain-Driven Design (DDD)

17 Ekim 2025 Eren Özşahiner

Günümüzün dijital dünyasında yazılım sistemleri, basit araçlar olmaktan çıkıp, kurumların temel iş yapış biçimlerini yansıtan karmaşık ekosistemlere dönüştü. Özellikle büyük ölçekli sistemler (large-scale systems), yüzlerce iş kuralı, onlarca entegrasyon ve sürekli değişen pazar gereksinimleriyle başa çıkmak zorundadır. Bu denli yüksek bir karmaşıklık, geleneksel yazılım geliştirme yaklaşımlarını yetersiz kılar. İşte tam bu noktada, yazılımı işin gerçek ihtiyaçlarına odaklayarak karmaşıklığı yönetilebilir parçalara ayıran felsefi bir yaklaşım olan Domain-Driven Design (DDD) devreye girer.

Domain-Driven Design (DDD), temel olarak, yazılımın kalbine iş alanının (domain) karmaşıklığını yerleştirmeyi amaçlar. Teknoloji, veritabanı veya framework’ler birer araçtır; asıl odak noktası, yazılımın hizmet ettiği “iş alanı” ve o alana ait kurallardır. Bu makalede, DDD’nin ne olduğunu, büyük ölçekli sistem mimarilerinde neden hayati önem taşıdığını ve bu yaklaşımın temel yapı taşlarını (hem stratejik hem de taktiksel olarak) detaylıca inceleyeceğiz.

Domain-Driven Design (DDD) Nedir?

Eric Evans tarafından 2003 yılında yayınlanan “Domain-Driven Design: Tackling Complexity in the Heart of Software” kitabı ile popülerleşen DDD, bir teknoloji veya bir framework değil, bir yazılım geliştirme felsefesi ve yaklaşımıdır.

Temel ilkesi şudur: Karmaşık bir iş alanına (domain) sahip projelerde, geliştirme ekibinin ana odağı, o iş alanını derinlemesine anlamak ve yazılım modelini doğrudan bu iş alanı modeli üzerine inşa etmek olmalıdır.

DDD, bu hedefe ulaşmak için iki ana kategoriye ayrılan bir dizi kavram ve desen sunar:

Stratejik Tasarım (Strategic Design): Sistemin büyük resmini, yani farklı iş alanlarının nasıl ayrıştırılacağını ve birbirleriyle nasıl iletişim kuracağını tanımlar. Büyük ölçekli mimariler için en kritik kısımdır.
Taktiksel Tasarım (Tactical Design): Stratejik olarak belirlenen sınırlar içerisindeki kodun nasıl organize edileceğine dair somut yapı taşları (building blocks) sunar.

Büyük Ölçekli Sistemlerde Neden DDD’ye İhtiyaç Duyarız?

Büyük ölçekli sistemler, genellikle “Büyük Çamur Topu” (Big Ball of Mud) olarak adlandırılan bir anti-desene dönüşme eğilimindedir. Bu, sistemin hiçbir parçasının diğerinden net bir şekilde ayrılamadığı, kodun iç içe geçtiği, bir değişikliğin beklenmedik yerlerde hatalara yol açtığı, bakımı imkansız hale gelen monolitik bir yapıdır.

DDD, bu kaosu önlemek için şu çözümleri sunar:

Karmaşıklığı Yalıtır: Sistemi, her biri kendi iş kuralı setine sahip daha küçük, yönetilebilir parçalara (Sınırlı Bağlamlar) ayırır.
İletişimi Güçlendirir: Yazılımcılar, iş analistleri ve iş alanı uzmanları (domain experts) arasında ortak bir dil (Evrensel Dil) oluşturarak yanlış anlamaların önüne geçer.
İş Odaklılık Sağlar: Teknolojiye değil, doğrudan işin değer üreten kısmına odaklanmayı sağlar. “Müşteri kaydı” ekranı yapmaktan çok, “Müşteri edinim sürecini” modellemeye odaklanırsınız.
Mimari Esneklik Sunar: DDD, özellikle Mikroservis Mimarisi için doğal bir temel oluşturur. Servis sınırlarının “teknik” (örneğin, ‘müşteri servisi’) değil, “iş alanı” (örneğin, ‘sadakat yönetimi bağlamı’) temelinde çizilmesini sağlar.

DDD’nin Temel Direkleri: Stratejik Tasarım

Stratejik Tasarım, mimarinin iskeletini oluşturur. Büyük ölçekli bir sistemi nasıl parçalayacağımızı ve bu parçaların nasıl konuşacağını belirler.

1. Evrensel Dil (Ubiquitous Language)

DDD’nin belki de en temel taşıdır. Evrensel Dil, proje üzerinde çalışan tüm paydaşların (yazılımcılar, yöneticiler, iş alanı uzmanları) kullandığı ortak bir terminolojidir.

Neden Önemli? Yazılım ekibi “Kullanıcı” derken, pazarlama ekibi “Abone”, finans ekibi ise “Mükellef” diyorsa, bu durum kodda kafa karıştırıcı modellere yol açar. User, Subscriber, TaxPayer gibi farklı nesneler, aslında aynı kavramın farklı yönlerini temsil edebilir veya tamamen farklı anlamlara gelebilir.
DDD Çözümü: Tüm ekip, tek bir kavram için tek bir terim üzerinde anlaşır. Eğer bir iş alanı uzmanı “Poliçe teklifi onaylandığında, müşteriye provizyon atanır” diyorsa, koddaki sınıfın adı Policy, metodun adı ApproveOffer ve ilgili olayın adı ProvisionAssignedToCustomer olmalıdır.
Kritik Nokta: Bu dil, iş alanı uzmanlarından “alınıp” teknik ekibe “tercüme edilmez”. Bu dil, iki tarafın birlikte geliştirdiği bir dildir ve doğrudan kodun içine yansır.

2. Sınırlı Bağlam (Bounded Context)

Evrensel Dil’in var olabilmesi için bir sınıra ihtiyacı vardır. Bir kelimenin anlamı, kullanıldığı bağlama göre değişir.

Örnek: Bir e-ticaret sistemini düşünün.
- Satış Bağlamı’nda (Sales Context): “Müşteri” kavramı, sepet bilgisi, geçmiş siparişleri ve indirim kuponları ile ilgilidir.
- Destek Bağlamı’nda (Support Context): “Müşteri” kavramı, açtığı destek talepleri, iletişim geçmişi ve memnuniyet skoru ile ilgilidir.
- Lojistik Bağlamı’nda (Shipping Context): “Müşteri” kavramı, sadece bir “Teslimat Adresi” ve “İletişim Numarası”ndan ibaret olabilir.

Bu üç bağlamda da “Müşteri”den bahsediyor olsak da, model (veri yapısı ve davranışları) tamamen farklıdır.

Sınırlı Bağlam (Bounded Context), bir Evrensel Dil’in ve o dile ait modelin geçerli olduğu, net bir şekilde tanımlanmış kavramsal sınırdır. Büyük ölçekli bir sistemi tasarlarken yaptığımız ilk iş, bu Sınırlı Bağlamları keşfetmektir. Bir monolitik yapıda bu bağlamlar modüller olabilirken, mikroservis mimarisinde her bir Sınırlı Bağlam genellikle bir veya daha fazla mikroservise karşılık gelir.

3. Bağlam Haritaları (Context Maps)

Sistemimizi Sınırlı Bağlamlara ayırdıktan sonra, bu bağlamların birbirleriyle nasıl ilişki kuracağını belirlememiz gerekir. Bağlam Haritası, bu ilişkileri görselleştiren ve tanımlayan bir araçtır. Bu, büyük ölçekli mimarinin “entegrasyon” katmanıdır.

En yaygın ilişki desenlerinden bazıları şunlardır:

Müşteri-Tedarikçi (Customer-Supplier): En yaygın ilişkidir. Bir bağlam (Müşteri), diğer bağlamın (Tedarikçi) sunduğu bir hizmete veya veriye ihtiyaç duyar. Tedarikçi ekip, Müşteri ekibin ihtiyaçlarına göre önceliklendirme yapar.
Paylaşılan Çekirdek (Shared Kernel): İki veya daha fazla bağlam, kodun (veya veritabanının) kritik bir bölümünü paylaşır. Bu, genellikle iki ekip arasında sıkı bir koordinasyon gerektirir ve risklidir. Genellikle kaçınılması tavsiye edilir ancak bazen kaçınılmaz olabilir (örneğin, ortak bir Para veya Birim kütüphanesi).
Yolsuzluğu Önleme Katmanı (Anti-Corruption Layer – ACL): Bir sistemin, özellikle de eski (legacy) veya dış bir sistemin “bozuk” veya uyumsuz modelinden korunması gerektiğinde kullanılır. ACL, iki sistem arasında bir “çevirmen” görevi görür. Modern bağlam, eski sistemin karmaşık veya istenmeyen modelini bilmek zorunda kalmaz; sadece ACL’nin sunduğu temiz arayüzle konuşur. Büyük ölçekli sistemlerde, monolitleri parçalarken ACL hayati bir tekniktir.
Uyumlu (Conformist): Bir bağlam, başka bir bağlamın modelini (Evrensel Dil’ini) sorgusuz sualsiz kabul eder ve ona uyum sağlar. Genellikle dış bir API’ye (örneğin, bir ödeme sağlayıcısının API’si) entegre olurken bu desen kullanılır.

Mimarinin İçini Doldurmak: Taktiksel Tasarım

Stratejik tasarım bize “nereye” sınırlar çizeceğimizi söylediyse, taktiksel tasarım bu sınırlar içinde kodu “nasıl” yazacağımızı söyler. Bu desenler, kodun iş kurallarını net bir şekilde yansıtmasını, test edilebilir ve sürdürülebilir olmasını sağlar.

1. Varlıklar (Entities)

Bir Varlık, bir kimliğe (identity) sahip olan ve zaman içinde durumu değişebilen bir nesnedir. İki Varlığı birbirinden ayırmak için özelliklerine değil, kimliğine bakarız.

Örnek: Musteri bir Varlıktır. Adı, soyadı veya adresi değişse bile, MusteriID‘si (örneğin, TC Kimlik No veya sistem tarafından atanan bir GUID) aynı kaldığı sürece o aynı müşteridir. Siparis de bir Varlıktır; durumu “Hazırlanıyor”dan “Kargolandı”ya değişebilir ama SiparisID‘si sabittir.

2. Değer Nesneleri (Value Objects)

Bir Değer Nesnesi, bir kimliğe sahip olmayan, sadece nitelikleri ile tanımlanan değişmez (immutable) bir nesnedir.

Örnek: Adres bir Değer Nesnesidir. “İstanbul, Şişli, A Sokak, No: 5” bilgisine sahip bir adresi, “İstanbul, Şişli, A Sokak, No: 6” yapan bir değişiklik, o adresi “güncellemek” değil, onu yeni bir adres nesnesi ile değiştirmektir. İki Adres nesnesinin aynı olup olmadığını anlamak için kimliklerine değil, içerdikleri tüm değerlerin (sokak, şehir, vb.) birebir aynı olup olmadığına bakarız.
Diğer Örnekler: Para (Miktar: 100, ParaBirimi: “TRY”), TarihAraligi (Baslangic, Bitis).
Faydası: Değer Nesneleri, sistemdeki yan etkileri azaltır, iş kurallarını (örneğin “Para miktarı negatif olamaz”) kendi içinde kapsüller ve modeli zenginleştirir.

3. Kümeler (Aggregates) ve Küme Kökü (Aggregate Root)

Bu, taktiksel tasarımın en önemli ve genellikle anlaşılması en zor kısmıdır. Büyük ölçekli sistemlerde veri bütünlüğünü (consistency) sağlamanın anahtarıdır.

Küme (Aggregate): Birbiriyle ilişkili Varlık ve Değer Nesnelerinden oluşan, bir bütün olarak ele alınan bir gruptur.
Küme Kökü (Aggregate Root): Kümenin içindeki bir Varlıktır ve o kümenin dış dünyayla olan tek iletişim noktasıdır (bir nevi kale kapısı).

Neden Gerekli? Bir e-ticaret sistemi düşünün. Bir Siparis (Entity) ve ona bağlı SiparisKalemi (Entity) listesi var. İş kuralı diyor ki: “Bir siparişin toplam tutarı 10.000 TL’yi geçemez.”

Kötü Tasarım: Dışarıdan bir kodun, Siparis nesnesinden habersiz, doğrudan SiparisKalemi listesine yeni bir kalem eklemesine izin verirseniz, bu kuralı ihlal edebilirsiniz. Veritabanı bütünlüğü bozulur.
Aggregate Tasarımı:Siparis nesnesini Aggregate Root olarak tanımlarız. SiparisKalemi ise bu Aggregate’in bir parçasıdır.
- Dış dünya (Application Service), SiparisKalemi listesine doğrudan erişemez.
- Yeni bir kalem eklemek için mutlaka Siparis Kökü üzerinden Siparis.YeniKalemEkle(urun, miktar) metodunu çağırmak zorundadır.
- Bu metot, iş kuralını (10.000 TL limiti) kontrol eder. Eğer kural ihlal edilmiyorsa kalemi ekler, ediliyorsa hata fırlatır.

Kritik Kural: Bir işlem (transaction), her zaman tek bir Aggregate üzerinde yapılmalıdır. Bir Aggregate Root’u kaydettiğinizde, içindeki tüm değişiklikler (yeni kalemler, adres değişikliği) atomik olarak kaydedilir.

4. Depolar (Repositories)

Repository, Aggregate’leri kalıcılık katmanından (veritabanı) soyutlayan bir desendir. Dışarıya bir “koleksiyon” gibi görünür.

Görevi: Kodun geri kalanının SQL, NoSQL veya Entity Framework gibi teknolojileri bilmesine gerek kalmadan Aggregate’leri “getirmesini” (retrieve) ve “kaydetmesini” (persist) sağlar.
Örnek: ISiparisRepository arayüzü (interface). GetById(SiparisId id) ve Save(Siparis siparis) gibi metotları olur.
Önemli Not: Repository’ler, sadece Aggregate Root’lar için tanımlanmalıdır. ISiparisKalemiRepository diye bir şey olmamalıdır; çünkü SiparisKalemi‘ne sadece Siparis Kökü üzerinden erişilmelidir.

5. Alan Hizmetleri (Domain Services)

Bazen bir iş kuralı veya operasyon, tek bir Varlık veya Değer Nesnesine ait değildir. Birden fazla nesneyi ilgilendiren veya “durumsuz” (stateless) olan bu iş mantığı, Alan Hizmetleri içinde yaşar.

Örnek: İki farklı banka hesabına ait Hesap Varlıkları arasında para transferi yapmak. Bu işlem Hesap1‘in mi, Hesap2‘nin mi sorumluluğudur? İkisinin de değil. Bu, bir ParaTransferService Alan Hizmetinin sorumluluğudur. Bu servis, iki Hesap nesnesini alır, işlemi gerçekleştirir (birinden düşer, diğerine ekler) ve sonucu döner.

DDD, Mikroservisler ve Olay Güdümlü Mimari (EDA)

Domain-Driven Design’ın büyük ölçekli sistemlerdeki en güçlü uygulaması, Mikroservis ve Olay Güdümlü Mimariler (Event-Driven Architecture) ile birleştiği yerdir.

DDD ve Mikroservis Sınırları

Mikroservis mimarisinin en zor sorusu şudur: “Bir servisi nerede bölmeliyim?”

Yanlış Yaklaşım: Teknoloj_k veya varlık bazlı bölmek. (Örn: MusteriServisi, UrunServisi, SiparisServisi). Bu, servisler arasında çok fazla senkron çağrıya (chatty communication) ve “dağıtık monolite” yol açar.
DDD Yaklaşımı: Servis sınırları, Sınırlı Bağlamlar (Bounded Contexts) temelinde çizilir.
- SiparisServisi yerine, SatisBaglamiServisi (Sipariş oluşturma, sepet yönetimi).
- MusteriServisi yerine, KimlikVeErisimBaglamiServisi (Login, yetkilendirme) ve MusteriDestekBaglamiServisi (Destek talepleri).

Bu yaklaşım, servislerin yüksek uyum (high cohesion) ve düşük bağımlılığa (low coupling) sahip olmasını sağlar.

Alan Olayları (Domain Events) ile Asenkron İletişim

Farklı Sınırlı Bağlamlar (veya mikroservisler) arasındaki ilişkiyi yönetmek için DDD, Alan Olayları (Domain Events) kavramını güçlü bir şekilde kullanır. Bir Alan Olayı, iş alanı açısından “önemli bir şeyin gerçekleştiğini” belirten bir mesajdır.

Örnek Akış:
1. Satış Bağlamı: Müşteri ödemeyi tamamlar. Siparis Aggregate’i, SiparisOnaylandiEvent adında bir olay yaratır ve bu olayı bir mesaj kuyruğuna (örneğin RabbitMQ veya Kafka gibi açık kaynaklı sistemler) yayınlar.
2. Lojistik Bağlamı: Bu olayı dinler (subscribe). Olayı aldığında, yeni bir “Kargo Gönderisi” oluşturur.
3. Bildirim Bağlamı: Aynı olayı dinler ve müşteriye “Siparişiniz onaylandı” e-postası gönderir.

Bu Olay Güdümlü Mimari (EDA) sayesinde:

Bağlamlar birbirinden tamamen ayrıştırılır (decoupled). Satış bağlamı, lojistik veya bildirimin varlığından haberdar olmak zorunda değildir.
Sistem dayanıklı (resilient) hale gelir. Bildirim servisi o an çalışmıyorsa bile, olay kuyrukta bekler ve servis ayağa kalktığında e-postayı gönderir. Satış işlemi etkilenmez.
Sistem ölçeklenebilir (scalable). Lojistik bağlamı çok yoğunlaşırsa, sadece o servisin çalışan sayısını artırabilirsiniz.

DDD Karmaşıklığa Karşı Bir Yatırımdır

Domain-Driven Design (DDD), “gümüş bir kurşun” değildir. Öğrenme eğrisi olan ve iş alanı uzmanlarıyla yakın çalışmayı gerektiren disiplinli bir yaklaşımdır. Basit CRUD (Create, Read, Update, Delete) operasyonlarından ibaret küçük bir blog sitesi için DDD uygulamak, aşırı mühendislik (over-engineering) olacaktır.

Ancak, konu büyük ölçekli, karmaşık ve sürekli gelişen kurumsal sistemler olduğunda, DDD bir lüks değil, bir zorunluluktur. Domain-Driven Design, iş alanının karmaşıklığını yazılımın tam merkezine alarak, değişime direnen “Büyük Çamur Topları” yerine, işin ihtiyaçlarına göre evrilebilen, bakımı yapılabilir, ölçeklenebilir ve esnek mimariler inşa etmemiz için bize stratejik ve taktiksel bir harita sunar. Bu, teknolojiden çok, işi anlama ve modelleme disiplinidir…

Lütfen Dikkat! Sitemizi kaynak göstermeden kesinlikle alıntı yapmayınız!!!

5G ve 6G’nin Geleceği: Altyapı Devrimi ve Güvenlik Labirenti
Mobil iletişim dünyası, her on yılda bir radikal bir dönüşüm geçiriyor. 1G ile sesli görüşmeleri mobil hale getirdik, 2G ile mesajlaşma devri başladı, 3G mobil interneti hayatlarımıza soktu ve 4G ile her şeyi anında yapabildiğimiz bir hız yakaladık. Şimdi ise 5G’nin getirdiği değişimin tam ortasındayız ve gözler 6G’nin vaat ettiği gelecekte. Ancak bu yeni nesil
Açık Kaynak AI Eğitim Platformları: Yapay Zeka Devrimine Kapıyı Aralayan Anahtar ve Uzmanı Olma Yolculuğu
Yapay zeka (AI), artık bilim kurgu filmlerinden çıkmış ve günlük hayatımızın her alanına nüfuz etmiş bir gerçeklik. Akıllı asistanlarımızdan öneri algoritmalarına, tıbbi teşhislerden otonom araçlara kadar her yerde yapay zekanın izlerini görüyoruz. Bu devrimsel teknolojinin getirdiği fırsatlar kadar, bir soru da akıllara geliyor: “Ben bu alanı nasıl öğrenebilirim, hangi AI Eğitim Platformları en iyileri?” Geçmişte,
Açık Kaynak Bilgisayarlı Görü: OpenCV ve YOLOv8 ile Görüntü İşleme Dünyasına Adım
Dijital çağın en heyecan verici ve dönüştürücü teknolojilerinden biri olan Bilgisayarlı Görü (Computer Vision), makinelerin insan gibi “görmesini” ve gördüklerini anlamlandırmasını sağlar. Otonom araçlardan yüz tanıma sistemlerine, tıbbi görüntü analizinden endüstriyel kalite kontrolüne kadar geniş bir uygulama yelpazesine sahip olan bu alan, dünyamızla etkileşim şeklimizi temelden değiştiriyor. Ancak mesela ilk etapta Açık Kaynak Bilgisayarlı Görü:
Açık Kaynak Büyük Dil Modelleri (LLM): AI Devrimi
Son birkaç yıl, yapay zeka (AI) alanında baş döndürücü bir hıza sahne oldu. ChatGPT, Claude ve Gemini gibi güçlü Büyük Dil Modelleri (Large Language Models – LLM), makinelerin insan dilini anlama, üretme ve onunla etkileşime girme biçiminde bir devrim yarattı. Ancak bu güçlü modellerin büyük çoğunluğu, “kapalı kaynak” veya “tescilli” sistemler olarak kaldı. Bu modellerin mimarileri,
Açık Kaynak Edge AI Çözümleri: Geleceği Cihazlarınıza Taşıyan Güç
Günümüzün dijital dünyasında yapay zeka (YZ), artık dev veri merkezlerinde yaşayan, uzak bir kavram değil. Aksine, ceplerimizdeki telefonlardan evimizdeki akıllı cihazlara, fabrikalardaki sensörlere kadar her yerde karşımıza çıkan bir gerçeklik haline geliyor. Bu devrimin arkasındaki en önemli teknolojilerden biri ise Edge AI. Peki, bu teknolojiyi herkes için erişilebilir kılan, inovasyonu teşvik eden ve maliyetleri düşüren
Açık Kaynak İşlemci Mimarileri: RISC-V ile Tasarım ve Üretim
Baştan beridir işlemci dünyası, bir elin parmaklarını geçmeyen global şirketlerin hakimiyetindeydi. Bilgisayarlarımızda x86 (Intel, AMD) ve mobil cihazlarımızda ARM mimarileri, kapalı kapılar ardında geliştirilen yüksek lisans ücretlerine tabi ve “kara kutu” olarak adlandırabileceğimiz tasarımlardı. Bir şirket veya bir geliştirici kendi özel işlemcisini tasarlamak istediğindeyse ya bu devlere yüksek bedeller ödemek ya da sıfırdan, devasa bir
Açık Kaynak Makine Öğrenimi Kütüphaneleri: Derin Öğrenmeden Veri Bilimine Bir Rehber
Yapay zeka ve makine öğrenimi (deep learning), günümüz teknolojisinin en hızlı gelişen alanlarından biridir. Bu devrimin arkasındaki itici güç ise büyük ölçüde açık kaynak makine öğrenimi (derin öğrenme – deep learning) kütüphaneleri tarafından sağlanmaktadır. Peki, bu kütüphaneler nelerdir ve neden bu kadar önemlidirler? Bu rehberde, TensorFlow ve PyTorch gibi devlerin karşılaştırmasından, Scikit-learn gibi temel araçlara kadar modern
Açık Kaynak Robotik ve Kontrol: ROS 2 ve OpenAI Gym ile Geleceği Kodlamak
Robotik, bir zamanlar sadece devasa endüstriyel tesislerin veya milyar dolarlık araştırma laboratuvarlarının ayrıcalığı olarak görülürdü. Ancak bugün, “açık kaynak” felsefesi sayesinde bu algı kökten değişti. Artık bir öğrenci, bir hobi uzmanı veya küçük bir girişim, küresel bir topluluğun ortak bilgeliğinden yararlanarak karmaşık otonom sistemler geliştirebiliyor. Bu devrimin merkezinde ise Açık Kaynak Robotik ve Kontrol araçları
Açık Kaynak Ses İşleme: Mozilla DeepSpeech, Whisper ve Diğer Önemli Projeler
Ses işleme teknolojileri, modern dijital dünyanın en hızlı gelişen alanlarından biri haline geldi. Sesli asistanlardan otomatik altyazı sistemlerine, podcast transkripsiyonundan müzik üretimine kadar uzanan geniş bir yelpazede kullanılan bu teknolojiler, günlük yaşamımızın vazgeçilmez parçaları olmaya devam ediyor. Açık kaynak ses işleme araçları, bu teknolojilere erişimi demokratikleştirerek geliştiricilerin, araştırmacıların ve girişimcilerin güçlü ses işleme yeteneklerini projelerine