Bir epin scripti satın alan ya da geliştiren hemen her işletme aynı noktaya varır: sistem ilk gün ihtiyacının yüzde doksanını karşılar, kalan yüzde onu ise tamamen sana özeldir. Kendi kargo bildirimin, kendi bayi indirim kuralın, kendi muhasebe aktarımın. Bu noktada çoğu kişi en kısa yolu seçer, bir yazılımcı bulur ve çekirdek dosyaların içine dokunulur. O gün işe yarar; sorun sonra çıkar.
İlk güncelleme geldiğinde o özel kod ya üzerine yazılır ya da çalışmaya devam edip sistemin yeni davranışıyla çakışır. Sonuç tanıdıktır: güncelleme yapılmaz, sürüm yıllarca eski kalır, güvenlik yamaları alınmaz ve sistem bir süre sonra dokunulamaz bir yapıya dönüşür. Eklenti mimarisi tam olarak bu kısır döngüyü kırmak için vardır. Bu yazıda bir dijital ürün satış yazılımı için genişletme mimarisinin nasıl kurulduğunu, hangi sözleşmelerin yazılması gerektiğini ve üçüncü parti koda ne kadar yetki verilebileceğini konuşuyoruz.
Her Talebi Çekirdeğe Yazmak Neden Seni Güncellemeden Mahrum Bırakıyor?
Çekirdeğe yazılan her satır, o dosyanın gelecekteki her sürümüyle senin sorumluluğun haline gelir. Sağlayıcı sipariş servisini yeniden düzenlediğinde senin eklediğin on satır bağlamını kaybeder. Çakışmayı çözmek için her güncellemede yazılımcı tutmak gerekir, bu da güncellemeyi maliyet kalemi yapar. Maliyet olan şey ertelenir.
Eklenti mimarisi bu ilişkiyi tersine çevirir. Çekirdek belirli noktalarda "burada bir şey yapmak isteyen var mı" diye sorar, senin kodun cevap verir. Çekirdek kendi içini istediği gibi değiştirebilir; sözü verilen nokta ve veri şekli aynı kaldığı sürece senin eklentin çalışmaya devam eder. Böylece güncelleme tehdit olmaktan çıkıp rutin bir işe döner ve işletmen güvenlik yamalarını kaçırmaz.
Eklenti Mimarisi Aslında Hangi Üç Sözleşmeden Oluşur?
Birincisi manifest sözleşmesi: her eklenti kendini tanıtan bir dosyayla gelir. Adı, sürümü, hangi çekirdek sürüm aralığıyla uyumlu olduğu, hangi izinleri istediği ve giriş noktası burada yazılıdır. Manifest olmadan kurulum, kaldırma ve uyumluluk kontrolü yapılamaz.
İkincisi yaşam döngüsü sözleşmesi: kurulum, etkinleştirme, devre dışı bırakma ve kaldırma adımları. Kurulumda tablo oluşturan bir eklenti, kaldırılırken ne yapacağını da bildirmek zorundadır. Üçüncüsü genişletme noktası sözleşmesi: çekirdeğin hangi olaylarda çağrı yaptığı ve o çağrıya hangi verinin verildiği. Bu üç sözleşme belgelenmişse üçüncü parti geliştirici senin çekirdeğini okumak zorunda kalmaz; belgeyi okur, eklentiyi yazar. Belgesiz bir e-pin scripti etrafında ekosistem kurulmaz.
| Genişletme yöntemi | Nasıl çalışır | Güncelleme dayanıklılığı | Uygun senaryo |
|---|---|---|---|
| Çekirdek dosya düzenleme | Kaynak kod doğrudan değiştirilir | Çok düşük | Hiçbiri |
| Olay dinleyici (hook) | Belirli noktada fonksiyon çağrılır | Yüksek | Bildirim, loglama, kural |
| Filtre (veri dönüştürücü) | Veri işlenmeden önce değiştirilir | Yüksek | Fiyat, indirim, metin |
| Servis geçersiz kılma | Arayüzün farklı uygulaması bağlanır | Orta | Ödeme, tedarikçi, kargo |
| Tema/şablon katmanı | Üst dizinde şablon aranır | Yüksek | Görsel özelleştirme |
| Dış servis + webhook | Mantık ayrı uygulamada çalışır | Çok yüksek | Ağır iş, ayrı ekip |
Hook mu Servis Konteyneri mi? Hangisi Senin Ölçeğine Uygun?
Hook tabanlı yaklaşım basittir: çekirdek order.delivered gibi noktalarda kayıtlı dinleyicileri sırayla çağırır. Öğrenme eğrisi düşüktür, küçük eklentiler için idealdir. Zayıf yanı görünürlüktür; on eklenti aynı noktaya bağlandığında sırayı ve yan etkileri takip etmek zorlaşır. Bu yüzden her dinleyiciye öncelik değeri verilmesi ve panelde hangi eklentinin hangi noktaya bağlı olduğunun listelenmesi gerekir.
Servis konteyneri yaklaşımı ise arayüz temellidir: ödeme sağlayıcısı için bir arayüz tanımlanır, eklenti o arayüzü uygulayan sınıfı kaydeder. Test edilebilirliği ve netliği yüksektir ama geliştiriciden daha fazla disiplin ister. Pratik cevap ikisini birlikte kullanmaktır: davranış ekleme için hook, bileşen değiştirme için arayüz. Bir epin yazılım altyapısında ödeme ve tedarikçi katmanları arayüzle, bildirim ve raporlama katmanları hook ile genişletilirse hem esneklik hem okunabilirlik korunur.
Eklentilerin Kullanım Amacına Göre Dağılımı
- Tedarikçi ve ödeme entegrasyonu 38%
- Bildirim ve otomasyon 28%
- Raporlama ve muhasebe aktarımı 20%
- Arayüz ve pazarlama modülleri 14%
Üçüncü Parti Koda Sınırsız Yetki Vermek Neyi Kırar?
Bir eklenti senin sunucunda senin haklarınla çalışır. Kısıtlama yoksa bayi bakiyelerini okuyabilir, tedarikçi anahtarlarını dışa gönderebilir, veritabanına serbestçe yazabilir. Bu yüzden mimarinin güvenlik tarafı, esneklik tarafı kadar önemlidir ve iki araca dayanır: izin bildirimi ve sınırlı erişim.
İzin bildirimi, eklentinin manifest dosyasında hangi kaynaklara erişmek istediğini açıkça yazmasıdır: sipariş okuma, ürün yazma, giden HTTP isteği. Panel kurulum sırasında bunu sana gösterir, sen onaylarsın. Sınırlı erişim ise eklentiye tam veritabanı bağlantısı yerine yalnızca ihtiyaç duyduğu servisleri vermektir. Üstüne üç pratik önlem koy: eklenti kendi tablolarını ön ek ile oluşturmalı, hata verdiğinde sipariş akışını düşürmemeli (hatası yakalanıp loglanmalı) ve her eklentinin yaptığı kritik işlem denetim kaydına düşmelidir. Kod imzalama veya en azından sürüm ve yayıncı doğrulaması ise pazar yeri açacaksan zorunlu hale gelir.
Her dinleyici çağrısını hata yakalama bloğu içinde çalıştır. Bir eklenti çökerse o eklenti devre dışı kalsın, sipariş tamamlanmaya devam etsin. Yoksa üçüncü parti bir hata senin ciro hattını kapatır.
Eklenti Sürümleri Çekirdek Güncellemesinde Neden Patlar?
Çünkü çoğu projede uyumluluk yazılı bir kural değil, sözlü bir varsayımdır. Çözüm anlamsal sürümleme disiplinidir: genişletme noktalarının şeklini bozan değişiklik ana sürümü artırır, geriye uyumlu eklemeler ara sürümü artırır. Eklenti manifesti hangi çekirdek aralığında çalıştığını yazar, panel kurulum sırasında bunu kontrol eder ve uyumsuz eklentiyi etkinleştirmez.
Bunun yanına iki alışkanlık gerekir. Birincisi kullanımdan kaldırma politikası: bir genişletme noktası kaldırılacaksa önce "artık önerilmiyor" olarak işaretlenir, en az bir sürüm boyunca çalışmaya devam eder ve geliştiricilere geçiş süresi verilir. İkincisi ön izleme ortamı: güncelleme canlıya çıkmadan önce kopya bir kurulumda eklentilerle birlikte denenir. Bu iki adım, "güncelleme sonrası hiçbir şey çalışmıyor" telefonlarını neredeyse tamamen bitirir.
Kendi Eklenti Ekosistemini Kurmak Sana Ne Kazandırır?
Bir satıcı için asıl kazanç zamandır. Yeni bir tedarikçiyle çalışmaya başladığında tüm sistemi elleme; sadece o tedarikçinin arayüz uygulamasını yaz ve kaydet. Yeni bir muhasebe programına geçtiğinde raporlama eklentisini değiştir. Sistem büyürken karmaşıklık çekirdeğe değil kenarlara birikir, bu da bakımı ucuz tutar.
İkinci kazanç pazarlık gücüdür. Özel kodun çekirdeğe gömülü olduğu bir işletme, yazılımcısına ve sağlayıcısına bağımlıdır. Eklenti olarak ayrılmış kod devredilebilir, denetlenebilir ve gerekirse başka bir ekibe teslim edilebilir. Pinova bu nedenle manifest tabanlı eklenti yapısı, izin bildirimi, öncelikli hook listesi ve sürüm uyumluluk kontrolüyle birlikte geliyor; kendi e-pin satış yazılımı özelleştirmelerini çekirdeğe dokunmadan taşıyabiliyorsun. Genişletme noktalarının listesini özellikler bölümünde, lisans ve destek farklarını fiyat sayfasında görebilirsin.
| Kontrol | Neden gerekli | Nasıl doğrularsın | Önem |
|---|---|---|---|
| Manifest dosyası zorunlu | Kurulum ve uyumluluk kontrolü | Eklenti klasöründe tanım dosyası | Kritik |
| Çekirdek sürüm aralığı yazılı | Uyumsuz kurulumu engeller | Panel uyarı veriyor mu | Kritik |
| İzin bildirimi gösteriliyor | Yetki şişmesini önler | Kurulum onay ekranı | Kritik |
| Hook hataları izole | Satış akışını korur | Bilinçli hata testi | Kritik |
| Dinleyici öncelikleri var | Sıra çakışmasını çözer | Eklenti liste ekranı | Yüksek |
| Kaldırma adımı tanımlı | Artık veri bırakmaz | Kaldır ve tabloları kontrol et | Yüksek |
| Şablon üst katmanı mevcut | Tasarımı güncellemeden korur | Şablon geçersiz kılma testi | Orta |
| Denetim kaydı tutuluyor | Kim ne yaptı sorusunu cevaplar | İşlem günlüğü | Orta |
Özelleştirmelerin güncellemelerden sağ çıksın
Manifest, izin bildirimi ve sürüm kontrolüyle gelen bir eklenti mimarisi üzerinde kendi kurallarını rahatça kur.
Mevcut sistemimde çekirdeğe yazılmış kod var, ne yapmalıyım?
Önce o kodun hangi olayda tetiklendiğini belirle, ardından aynı işi yapan bir dinleyiciye taşı ve çekirdek dosyayı orijinal haline döndür. Genellikle bir eklenti başına yarım günlük iştir.
Eklenti yazmak için ne kadar teknik bilgi gerekir?
Belgelenmiş bir mimaride orta seviye PHP bilgisi yeterlidir. Geliştiricinin çekirdeği okumasına gerek yoktur; manifest, yaşam döngüsü ve genişletme noktası belgeleri işi görür.
Üçüncü parti eklentiye güvenmem gerekir mi?
Körü körüne hayır. İzin bildirimini oku, yayıncıyı doğrula, önce kopya kurulumda dene ve denetim kaydını izle. Sınırlı yetki, güvenden daha sağlam bir korumadır.
Eklenti mimarisi performansı düşürür mü?
Doğru kurulunca ölçülemeyecek kadar az. Asıl risk, senkron dinleyicilerin içinde ağır iş yapmaktır; böyle işler kuyruğa alınmalı, akış içinde çalıştırılmamalıdır.
Genişletme mimarisi, bugünkü ihtiyacını değil önümüzdeki üç yılın taleplerini karşılamak için kurulur; çekirdeği temiz tutan işletme her güncellemede güçlenir, gömülü kodla çalışan işletme her güncellemede zayıflar. Kendi senaryonu test etmek istiyorsan canlı demo üzerinden eklenti yönetimi ekranını aç, izin bildirimlerini ve genişletme noktası listesini incele; kendi özel kuralını nereye bağlayacağını görmek, karar vermeni bir toplantıdan daha hızlı kolaylaştıracak.