# 11 — BAĞIMSIZLAŞMA: Botble Yüzeyini Küçültmek Karar: güncelleme almıyoruz, kendi sistemimizle devam ediyoruz. Bu doküman o kararın nasıl **çalışır** hale getirileceğini anlatıyor. Çünkü "namespace'i değiştirip kendi ürünümüz yapalım" yolu teknik olarak kapalı, ama istediğin sonuca götüren başka bir yol var ve zaten yarısını yürüdük. --- ## 1. Namespace değiştirmek neden işlemiyor İlk açıklamamda gerekçeyi yanlış yere koymuşum. "Güncelleme kırılır" dedim; güncelleme almayacaksan o argüman düşer. Haklıydın. Asıl engel şu: `Botble\` namespace'i sadece `platform/` altında değil, **packagist'ten gelen paketlerin içinde.** ``` vendor/botble/ → 20 paket, 11.875 dosya platform/ → 20.787 dosya ``` `platform/core` ve `platform/packages` klasörleri `wikimedia/composer-merge-plugin` ile bu vendor paketlerinden birleşiyor. Yani yeniden adlandırma ~32.000 dosya. Ve mekanik zorluk değil asıl sorun. Sorun şu: **composer'ı terk etmek zorunda kalırsın.** `composer dump-autoload` çalıştığı an autoload haritası `composer.json`'daki `botble/*` paketlerinden yeniden üretilir ve senin değişikliğin uçar. Bunun bedelini Faz 3'ün kalan işleri ödüyor: | Yapılacak iş | Composer'dan gelecek | |---|---| | e-Arşiv / e-Fatura | Entegratör SDK'sı (Nilvera, Uyumsoft, Paraşüt) | | Kargo entegrasyonu | Yurtiçi/Aras/MNG API istemcileri veya guzzle sarmalayıcı | | PDF (kargo etiketi, fatura) | dompdf / snappy | | Excel içe-dışa aktarma | maatwebsite/excel | | Görsel işleme | intervention/image | Composer masadan kalkarsa bunların hiçbirini kuramazsın. Namespace kozmetiği için ödenmesi çok pahalı bir bedel. **Ve gerek de yok:** müşterin, satıcın, rakibin `Botble\` yazısını hiçbir yerde görmüyor. Görünür markanın tamamı Magostore. Namespace'i gören tek kişi kod tabanına erişen geliştiricin. --- ## 2. Doğru dondurma yöntemi Güncelleme almamak "hiçbir şey yapmamak" değil, **bilinçli kilitlemek.** ### Bugünkü tehlike: 14 paket `*@dev` `composer.json` şu an şöyle: ```json "botble/platform": "*@dev", "botble/theme": "*@dev", "botble/menu": "*@dev", ... ``` `*@dev` "en son geliştirme sürümü" demek. Biri `composer update` çalıştırırsa ne indiğini kimse bilmiyor — muhtemelen çalışmayan bir sistem. 14 paket bu durumda. ### Kural seti **1. `composer.lock` kutsaldır.** Gerçek kilit o, `composer.json` değil. 564 KB'lık bu dosya hangi paketin hangi commit'inde olduğunu tutuyor. Sürüm kontrolüne al, asla silme. **2. `composer install` evet, `composer update` HAYIR.** - `install` → lock dosyasına birebir uyar. Güvenli. - `update` → lock'u yok sayar, yeni sürüm çeker. **Yasak.** Sunucuda yanlışlıkla çalıştırılmasını engelle: ```bash # ~/magostore/.git/hooks/pre-commit veya deploy betiğine if [ "$1" = "update" ]; then echo "composer update YASAK"; exit 1; fi ``` **3. Vendor klasörünü yedekle.** `vendor/` sürüm kontrolünde tutmak normalde kötü pratiktir, ama dondurulmuş bir forkta doğru olan bu. `*@dev` paketler packagist'ten kaybolursa veya değişirse elinde kopya kalır. **4. Kurulumdan sonra `composer.json`'daki `*@dev`'leri sabitleyin.** `composer.lock`'tan gerçek sürümleri okuyup `composer.json`'a yazmak, kazayı azaltır: ```bash php -r '$l=json_decode(file_get_contents("composer.lock"),true); foreach($l["packages"] as $p) if(str_starts_with($p["name"],"botble/")) echo $p["name"].": ".$p["version"]."\n";' ``` --- ## 3. Vazgeçemeyeceğin tek şey: güvenlik yamaları Bu, kararın gerçek maliyeti ve fiyatlandırılması gerekiyor. Sistem şunları taşıyor: ödeme akışı, kart ödeme yönlendirmesi, müşteri kişisel verisi (KVKK), satıcı banka bilgileri (IBAN, vergi no). Yamalanmamış bir Laravel veya guzzle açığı bu verilerin tamamını riske atar. ### Önerilen orta yol Botble güncellemesi almıyoruz — ama **çerçeve güvenlik yamalarını alıyoruz.** İkisi ayrı şey: | Ne | Politika | |---|---| | `botble/*` paketleri | Dondurulmuş. Güncelleme yok. | | `laravel/framework` | Yalnızca **yama** sürümü (12.48.1 → 12.48.x) | | `guzzlehttp/guzzle`, `predis`, `doctrine/dbal`, `symfony/*` | Güvenlik danışmanlığı çıkarsa yama | | Diğer her şey | Dondurulmuş | Ayda bir, 10 dakikalık kontrol: ```bash composer audit # bilinen açıkları listeler, hiçbir şey değiştirmez ``` Açık çıkarsa: **önce test sunucusunda** o paketi tek başına yamala: ```bash composer update laravel/framework --with-dependencies --dry-run ``` `--dry-run` ne olacağını gösterir, hiçbir şeyi değiştirmez. Sonucu görüp karar verirsin. > Bunu atlarsan sistem bir gün çalışmaz hale gelmez — sessizce savunmasız > kalır. Fark bu, ve tam da bu yüzden takvime yazılmalı. --- ## 4. Asıl strateji: yüzeyi küçültmek "Kendi sistemimiz olsun" hedefine namespace değiştirerek değil, **Botble'ın yaptığı işleri tek tek devralarak** gidiliyor. Buna yazılımda *strangler* deniyor: dış kabuk aynı kalır, içi parça parça değişir. ### Bugün elimizde olan | Alan | Sahip | Not | |---|---|---| | Para defteri (çift taraflı) | **Bizim** | 3 sınıf, 11 tablo | | Hakediş yaşam döngüsü | **Bizim** | Teslim, onay, iade, mahsup | | iyzico pazaryeri entegrasyonu | **Bizim** | Alt üye, onay, mutabakat | | Stopaj ve komisyon hesabı | **Bizim** | Kırılım bazlı | | İş günü takvimi | **Bizim** | Resmî tatil, 5 iş günü sınırı | | IBAN / GTIN doğrulama | **Bizim** | mod-97, GS1 modulo-10 | | Ortak katalog + buybox | **Bizim** | Motor hazır, bağlanacak | | Ürün/sipariş modelleri, sepet | Botble | | | Kimlik doğrulama, yetki | Botble | | | Admin CRUD iskeleti, medya | Botble | | | Tema motoru | Botble | | **23 sınıf, 23 tablo, 7 migration tamamen bizim.** Botble'ın hakediş sistemi (`mp_customer_revenues`) artık gerçeğin kaynağı değil, defterden beslenen bir projeksiyon. Yani o alanı fiilen devraldık. ### Sırada devralınacaklar — değer/risk sırasına göre **1. Kargo katmanı** — zaten sıfırdan yazılıyor, Botble'da karşılığı yok. `shippy` eklentisi TR'de işe yaramıyor, kaldırılacak. Doğal olarak bizim. **2. Sipariş durum makinesi** — Botble'ın durumları genel. Faz 2'de tanımladığımız 20 durum (kargoya hazır, transfer merkezinde, iade satıcıya ulaştı…) kendi durum makinemizi gerektiriyor. Botble'ın durumu bir alan olarak kalır, gerçek akış bizde. **3. Arama** — Botble'ın araması `LIKE` tabanlı ve zayıf. Faz 4'te fiyat teklife taşındığı için nasılsa yeniden yazılacak. Meilisearch veya Typesense ile tamamen bizim olur. **4. Ürün okuma yolu** — Faz 4'ün ana işi. Bitince liste, arama, detay ve sepet katalogdan okuyor; Botble'ın ürün modeli sadece görsel/varyant deposu olur. **5. Bildirim motoru** — SMS, e-posta, mobil push şablonları. Botble'ın bildirimi temel; bizim ihtiyacımız 17 farklı bildirim tipi. Bu beşi bittiğinde Botble'ın taşıdığı iş **kimlik doğrulama, yetkilendirme, admin CRUD iskeleti, medya kütüphanesi ve tema motoru**na iner. Yani bir uygulama çerçevesi seviyesine — Laravel'i kullanmaktan farkı kalmaz. ### Disiplin kuralı **Her yeni özellik `App\Magostore\` altına yazılır. Botble eklentisi yamalanmaz.** Bunu ilk günden uyguladık: para akışının tamamı hook üzerinden bağlandı, eklenti dosyalarına hiç dokunulmadı. Bu disiplin korunursa yüzey kendiliğinden küçülür. Bozulursa — bir kere "şu satırı platform/ içinde düzeltelim" denirse — geri dönüşü zor bir bağ oluşur. --- ## 5. Değişmeyen iki şey **Telif ve lisans notları kalır.** Güncelleme almaktan bağımsız. `vendor/` ve `platform/` altındaki LICENSE dosyaları ve dosya başlıklarındaki telif satırları yerinde durur. Bu bir teknik tercih değil. **Dağıtım hakkı yok.** Satın aldığın lisans kendi pazaryerini çalıştırma hakkı. Kod tabanını üçüncü kişilere vermek, satmak veya açık depoya koymak kapsamda değil. Kendi sunucunda, kendi işin için çalıştırmak — evet, sınırsız. --- ## 6. Sıradaki iş Bu doküman bir karar dokümanı, kod değil. Yapılacaklar: 1. **Kurulumdan hemen sonra:** `composer.lock`'u sürüm kontrolüne al, `*@dev` sürümlerini sabitle, deploy betiğine `composer update` engeli koy 2. **Takvime yaz:** ayda bir `composer audit` 3. **Devam:** kargo katmanı (Faz 3c'nin kalanı) — hem canlıya çıkış engeli, hem doğal olarak bizim olan ilk büyük alan Kargo entegrasyonuna başlayabiliriz. Hangi firmayla anlaştığını söylersen onun API'siyle başlarım; anlaşma yoksa Yurtiçi'nden başlamayı öneriyorum — dokümantasyonu en oturmuş olan o.