Golden Glass Next.js E-Ticaret: Gerçek Proje Mimarisi

Projenin kapsamı neydi?

Golden Glass, dekoratif cam tablo ürünleri için mağaza ön yüzü ile operasyon panelini aynı uygulama içinde birleştiren e-ticaret projesidir. Kaynak yapısında ziyaretçiye açık ürün, koleksiyon, ürün detayı, sepet, checkout, sipariş sonucu, sipariş takibi, üyelik, blog, arama, iletişim ve yasal sayfalar bulunuyor.

Yönetim tarafında ürün, kategori, sipariş, kupon, yorum, banner, banka havalesi, finans, mesaj, iletişim ayarı, sayfa içerikleri, kargo ve kullanıcı ayarları için ayrı ekranlar tespit edildi. Bu kapsam, yalnızca ürün kartları gösteren bir katalogdan farklı olarak satış ve içerik operasyonunun birlikte ele alındığını gösteriyor.

Neden hazır bir ürün kataloğu yeterli değildi?

Ürün satışı yapan bir işletmede ziyaretçi deneyimi ile arka ofis operasyonu birbirine bağlıdır. Ürün adı veya fiyatı değiştiğinde kategori, arama, sepet ve sipariş ekranlarında tutarlı görünmelidir. Kampanya koşulu, kupon limiti, banka hesabı veya kargo ayarı yönetici tarafından değiştirilebilmelidir. Mesaj ve sipariş bildirimleri operasyon ekibine ulaşmalıdır.

Bu gereksinimler ayrı eklentilerle de kurulabilir; ancak proje klasöründe özel shop ve admin katmanlarının birlikte tasarlandığı görülüyor. Amaç teknoloji göstermek değil, ürün ve sipariş verisinin tek bir uygulama mantığı içinde yönetilmesini sağlamaktır.

Mağaza mimarisi

Next.js App Router yapısında app/(shop) route grubu ziyaretçiye açık mağaza deneyimini topluyor. Ürün listesi, koleksiyon, detay, arama ve blog keşif katmanını; sepet, checkout, sipariş sonucu ve sipariş takibi işlem katmanını oluşturuyor. Hesap, giriş, kayıt ve parola yenileme sayfaları müşteri kimliği akışını tamamlıyor.

Route grubu kullanılması, URL'ye zorunlu bir “shop” öneki eklemeden mağaza sayfalarını ortak layout altında düzenlemeye yarar. Header, footer, sepet durumu ve genel sağlayıcılar bu alanda ortak yönetilebilir. Bu yapı, yönetim panelinin farklı layout ve erişim kurallarıyla ayrılmasını kolaylaştırır.

Yönetim paneli ve operasyon

Yönetim klasöründe dashboard yanında ürün, kategori, sipariş, yorum, kupon, banka havalesi, finans, gelen kutusu, mesaj, banner, sayfa, iletişim, kargo ve ayar ekranları bulunuyor. Bu dağılım, mağazanın günlük operasyonunda yalnızca ürün eklemenin değil, sipariş ve müşteri iletişiminin de merkezi olduğunu gösterir.

İyi bir admin paneli tüm veriyi göstermekle yetinmez. Rol ve yetkiye göre doğru işi hızlı yaptırmalı, hatalı girişleri engellemeli ve kritik değişikliklerin etkisini görünür kılmalıdır. Bu klasör yapısı kapsamı kanıtlar; kullanıcı testinin sonuçlarını veya operasyon hızındaki artışı tek başına kanıtlamaz. Bu nedenle sayısal verim iddiası kullanılmıyor.

Ürün ve kategori veri modeli

ProductContext ve CategoryContext dosyalarında ürünlerin kategori ilişkisi, aktiflik durumu ve kategori sıralaması gibi davranışlar görülüyor. Kategorilerde üst-alt ilişki ve sıralama desteği bulunması, düz ürün listesinden daha zengin bir gezinme modeli hedeflendiğini gösterir.

E-ticarette veri modeli SEO ve operasyonu birlikte etkiler. Ürün kimliği, slug, kategori, varyant, fiyat, stok, görsel, açıklama ve durum alanları tutarlı değilse filtre, site haritası, canonical ve kampanya kuralları da bozulur. Veri içe aktarılırken aynı ürünün yinelenmesi veya kategori bağının kopması için doğrulama gerekir.

Sepet, checkout ve sipariş

CartContext, checkout sayfası, orders API route'u, sipariş başarı ve takip sayfaları satış akışının temel parçalarını oluşturuyor. Sepet istemci deneyimini yönetirken siparişin sunucu tarafında güvenilir biçimde kaydedilmesi gerekir. Fiyat ve indirim gibi kritik değerler yalnızca tarayıcıdan gelen veriye güvenilerek kabul edilmemelidir.

Checkout tasarımında adres, iletişim, ödeme yöntemi, kargo ve sözleşme adımlarının açık olması gerekir. Hata durumunda kullanıcının sepeti kaybetmemesi, tekrar denemenin yinelenen sipariş oluşturmaması ve yönetim panelinin sipariş durumunu doğru göstermesi test edilmelidir.

Kupon ve kampanya kuralları

CouponContext içinde kod bulma, aktiflik, son kullanma tarihi, maksimum kullanım ve minimum sipariş tutarı kontrolleri görülüyor. Bu, kuponun yalnızca bir metin alanı olmadığını; birden fazla iş kuralını birlikte uyguladığını gösterir. Kullanım sayısının güncellenmesi ve eş zamanlı siparişlerde sınırın aşılmaması sunucu tarafında da güvenceye alınmalıdır.

Kampanya sistemlerinde test matrisi hazırlanmalıdır: geçersiz kod, süresi dolmuş kod, pasif kupon, alt limit, kullanım limiti, büyük-küçük harf, aynı kullanıcının tekrar kullanımı ve iptal edilen siparişin kupon hakkına etkisi. Görünen indirim ile kaydedilen sipariş toplamı aynı olmalıdır.

Banka havalesi ve ödeme bilgileri

BankContext ve banka havalesi yönetim sayfaları, ödeme seçeneklerinin panelden yönetilmesini hedefliyor. Banka adı, hesap bilgileri ve aktiflik gibi alanların kod içine gömülmemesi operasyonel değişiklikleri kolaylaştırır. Ziyaretçiye gösterilen bilgilerin güncel ve doğru olması kritik olduğundan değişiklik yetkisi sınırlanmalıdır.

Projede görülen banka havalesi altyapısı, doğrudan sanal POS entegrasyonunun tamamlandığını kanıtlamaz. Bir vaka analizinde kaynakta bulunmayan ödeme sağlayıcısı veya başarı oranı eklemek doğru olmaz. Yeni bir projede ödeme kuruluşu seçimi, 3D Secure, webhook, iade ve mutabakat gereksinimleri ayrıca planlanmalıdır.

Sipariş e-postası ve mesajlaşma

package.json içinde Nodemailer, API katmanında send-order-email route'u bulunuyor. Bu kanıt sipariş bildirimi için e-posta akışının geliştirildiğini gösterir. E-posta; müşteriye sipariş özeti, işletmeye yeni sipariş bildirimi veya durum değişikliği göndermek için kullanılabilir.

E-posta gönderildi yanıtı almak, mesajın gelen kutusuna ulaştığını garanti etmez. SPF, DKIM, DMARC, gönderici alan adı, hata kaydı ve yeniden deneme mekanizması izlenmelidir. Sipariş kaydı e-posta başarısına bağlanmamalı; e-posta servisi geçici olarak çalışmasa bile sipariş güvenli biçimde saklanmalıdır.

İçerik, blog, banner ve sayfa yönetimi

BlogContext, BannerContext, PageContext ve SettingsContext; mağaza içeriğinin kod dağıtımı olmadan güncellenebilmesi için ayrı yönetim alanları bulunduğunu gösteriyor. Blog yalnızca trafik için değil, ürün kullanımı, bakım, kategori rehberi ve sık sorulan sorular üzerinden satın alma kararını desteklemek için kullanılabilir.

İçerik modeli hazırlanırken başlık, özet, slug, görsel, yayın durumu, tarih, yazar, canonical ve ilişkili ürün/kategori alanları düşünülmelidir. Banner yönetiminde masaüstü ve mobil görsel, alternatif metin, hedef bağlantı ve yayın süresi gibi alanlar performans ve erişilebilirliği etkiler.

Firebase, Redis ve veri erişimi

Bağımlılıklarda Firebase ve ioredis görülüyor; context dosyalarının bazı sürümlerinde Firestore gerçek zamanlı dinleme, bazı sürümlerinde API veya yerel depolama yaklaşımları bulunuyor. Proje klasöründe aynı dosyanın numaralı kopyalarının olması, geliştirme sırasında alternatiflerin veya yedeklerin tutulduğunu düşündürüyor.

Bu durum vaka açısından önemli bir ders verir: üretime çıkmadan önce tek veri kaynağı ve kalıcı mimari netleştirilmelidir. Aynı varlığın Firestore, Redis ve localStorage arasında farklı sürümleri kalırsa veri tutarsızlığı ve bakım maliyeti oluşur. Kullanılmayan kopyalar temizlenmeli, migration ve yedekleme planı belgelenmelidir.

XLSX ve PDF yetenekleri

package.json içinde XLSX ve jsPDF bağımlılıkları bulunması, tablo verisi içe/dışa aktarma veya PDF çıktı senaryolarının değerlendirildiğini gösterir. Ancak yalnızca bağımlılığın bulunması her ekranın tamamlandığını kanıtlamaz. Vaka yazısında bu nedenle “altyapıda yer alıyor” ifadesi kullanılıyor, işletme sonucuna dönüştürülmüyor.

Toplu ürün aktarımında sütun eşleme, zorunlu alan, veri tipi, görsel URL'si, yinelenen SKU ve hatalı satır raporu gerekir. PDF sipariş veya rapor çıktısında Türkçe karakter, para formatı, sayfa taşması ve mobil indirme test edilmelidir.

SEO ve keşfedilebilirlik gereksinimleri

Next.js kullanmak tek başına SEO başarısı sağlamaz. Ürün ve kategori sayfalarında benzersiz başlık, açıklama, canonical, erişilebilir ürün bilgisi, Product ve Breadcrumb schema, anlamlı URL, site haritası ve doğru durum kodları gerekir. Filtre parametrelerinin indeks davranışı özellikle planlanmalıdır.

Blog ve kategori içerikleri kullanıcı sorularına kısa cevap verirken ürün sayfalarına bağlanmalıdır. Stokta olmayan ürünün silinmesi yerine uygun yönlendirme veya alternatif ürün gösterimi değerlendirilmelidir. AI görünürlüğü için marka, iletişim, teslimat, iade ve ürün bilgileri sayfalar arasında tutarlı olmalıdır.

Test edilmesi gereken kritik senaryolar

E-ticaret testleri yalnızca ana sayfanın açılmasıyla tamamlanmaz. Ürün bulunamadı, stok değişimi, kupon sınırı, eksik adres, başarısız e-posta, çift tıklama, oturum süresi, mobil klavye, yavaş ağ ve yönetici yetkisi gibi durumlar denenmelidir. Sipariş toplamı istemci ve sunucu tarafında aynı kurallarla doğrulanmalıdır.

Yayın öncesinde test verisi ile gerçek müşteri verisi ayrılmalı, yönetici hesapları güçlendirilmeli, yedek ve geri dönüş planı hazırlanmalıdır. İzleme; API hata oranı, e-posta hatası, başarısız checkout, 404, Core Web Vitals ve sipariş durumlarındaki gecikmeleri kapsamalıdır.

• Mobil ürün keşfi, filtre, sepet ve checkout
• Kuponun tüm geçerli ve geçersiz durumları
• Yinelenen sipariş ve tekrar deneme davranışı
• Sipariş e-postası başarısızken sipariş kaydı
• Yetkisiz kullanıcının admin API erişimi
• Ürün silme, pasife alma ve eski URL davranışı
• Yedekten geri yükleme ve veri dışa aktarımı

Doğrulanabilen sonuçlar ve bilinmeyenler

Kaynak klasörü, mağaza ve admin alanlarının tek Next.js projesinde toplandığını; ürün, kategori, sipariş, kupon, blog, mesaj, banka hesabı, ayar ve e-posta modüllerinin geliştirildiğini doğruluyor. Bu, teknik kapsam ve uygulanan çözüm hakkında güvenilir kanıttır.

Buna karşılık başlangıç dönüşüm oranı, yayın sonrası sipariş artışı, kullanıcı sayısı, gelir, Lighthouse saha verisi veya operasyon süresi için doğrulanabilir analitik ekranı bulunmuyor. Bu nedenle “%140 dönüşüm”, “X kat satış” veya “kusursuz performans” gibi ifadeler kullanılmadı. Gerçek vaka güveni, bilinmeyeni açıkça belirtmekle güçlenir.

Benzer proje için önerilen yol haritası

Benzer bir e-ticaret projesi önce ürün ve operasyon keşfiyle başlamalıdır. Ürün veri yapısı, varyant, fiyat, stok, kargo, ödeme, iade, kullanıcı rolleri, içerik ve entegrasyonlar çıkarılır. İlk sürümde satış için zorunlu akışlar seçilir; ikincil rapor ve otomasyonlar ölçümlere göre sonraki faza bırakılır.

Mimari seçimi, WordPress/WooCommerce ile özel Next.js uygulaması arasında gereksinime göre yapılmalıdır. Standart mağazada hazır altyapı daha hızlı olabilir. Özel ürün uygunluğu, bayi, yoğun entegrasyon veya benzersiz operasyon varsa özel geliştirme gerekçelendirilir. Her iki durumda da veri sahipliği, test, güvenlik ve bakım planı sözleşmede yer almalıdır.

Yayın sonrası hangi veriler izlenmeli?

Yayın sonrasında teknik ve ticari göstergeler aynı panelde değerlendirilmelidir. Ürün görüntüleme, sepete ekleme, checkout başlatma, başarılı sipariş, kupon kullanımı, başarısız form, API hatası ve e-posta hatası ayrı olaylar olarak ölçülebilir. Bu ölçüm başlangıç değeri oluşturur ve sonraki iyileştirmelerin etkisini doğrulamayı mümkün kılar.

Dönüşüm oranı tek başına yeterli değildir. Trafik kaynağı, cihaz, ürün kategorisi, sepet tutarı ve yeni/geri dönen kullanıcı ayrımı sonuçları açıklamaya yardımcı olur. Ölçüm kurulmadan yapılan tasarım değişikliğine satış artışı atfetmek güvenilir değildir; Golden Glass için de doğrulanmış yayın verisi bulunmadığından sonuç iddiası yerine ölçülmesi gereken göstergeler açıklanmıştır.

Sık Sorulan Sorular