Laravel, web uygulamalarında yönlendirme, doğrulama, veritabanı erişimi, kuyruk, önbellek ve test gibi ortak ihtiyaçları tutarlı araçlarla çözmeyi kolaylaştırır. Fakat frameworkün sunduğu her özelliği aynı projeye eklemek iyi mimari değildir. Sağlam yapı; iş gereksinimini, değişme nedenlerini, güvenlik sınırlarını ve operasyonel yükü anlaşılır hâle getirir.
Bu rehber, yeni bir Laravel projesini “hangi klasöre ne koymalıyım?” sorusundan üretim ortamına kadar ele alır. Sürüm seçimi, controller sınırları, service container, Form Request, policy, Eloquent, queue, test ve deployment adımlarını tek akışta birleştirir.
Önce uygulamanın kullanıcılarını, temel iş akışlarını, veri sahipliğini ve yüksek riskli işlemlerini yazın. Bir yönetim paneli, API, pazar yeri veya içerik sitesi aynı mimari önceliklere sahip değildir. Kullanıcı sayısından önce veri tutarlılığı, yetki modeli, dış servisler ve bakım sorumluluğu anlaşılmalıdır.
Minimum uygulanabilir kapsamı belirleyin. Kimlik doğrulama, ödeme, dosya yükleme, e-posta, arama, raporlama ve çoklu kiracı gibi özelliklerin hangilerinin ilk sürümde gerekli olduğunu ayırın. Mimari, gelecekte olabilecek her şeyi değil; bugün bilinen riskleri anlaşılır sınırlarla yönetmelidir.
Resmî Laravel dokümantasyonunda projenizin ana sürümünü seçerek PHP gereksinimini, yükseltme notlarını ve özellik davranışını kontrol edin. “En yeni” sürümü körlemesine seçmek yerine paket uyumu, barındırma desteği ve bakım takvimini değerlendirin.
composer.json içinde PHP ve paket sürüm kurallarını açıkça tanımlayın; composer.lock dosyasını uygulama deposunda saklayın. Geliştirme, CI ve üretimde aynı ana PHP sürümünü kullanmaya çalışın. Güncellemeleri küçük, test edilebilir paketler hâlinde yapın.
app dizini uygulama kodunun ana alanıdır; routes giriş noktalarını, config yapılandırma tanımlarını, database migration ve seed dosyalarını, resources görünüm ve ön uç kaynaklarını, tests ise otomatik testleri barındırır. public, web sunucusunun belge kökü olmalıdır.
storage ve bootstrap/cache için yazma izinleri gerekir; fakat geniş ve kontrolsüz dosya izinlerinden kaçının. .env, kaynak kodu ve loglar doğrudan web üzerinden erişilebilir olmamalıdır. Klasörleri yalnız estetik için çoğaltmak yerine sorumluluk büyüdükçe ayırın.
Route, HTTP yöntemi ve URL’yi doğru handler’a bağlar. Controller; isteği alır, doğrulama ve yetki akışını tetikler, uygulama servisini çağırır ve yanıt üretir. Büyük SQL sorguları, karmaşık fiyat hesapları ve dış servis ayrıntıları controller içinde birikmemelidir.
Resource controller ve route model binding tekrar eden kodu azaltabilir. Ancak otomatik model bağlama yetkilendirme değildir. Bir kaydın URL’den bulunması, mevcut kullanıcının onu görme veya değiştirme hakkı olduğu anlamına gelmez.
İnce controller hiç mantık içermeyen controller değildir. HTTP’ye ait kararları tutar; tekrar kullanılacak iş kurallarını action veya service sınıflarına yönlendirir. Aşırı katman üretmeden, test ve değişiklik ihtiyacına göre sınır çizin.
Girdi doğrulama; alanın zorunlu olup olmadığı, biçim, boyut ve ilişkili kuralları kontrol eder. Karmaşık isteklerde Form Request, doğrulama ile isteğe özel authorization kontrolünü ayrı bir sınıfta toplar. Laravel’in validation belgesi kuralları ve hata davranışını açıklar.
Doğrulanmış veri, güvenilir iş kararı anlamına gelmez. “Tutar sayıdır” biçim doğrulamasıdır; kullanıcının bu siparişe indirim uygulama hakkı iş kuralıdır. İkisini ayrı test edin. Dosya yüklemede MIME, boyut, içerik, saklama alanı ve erişim kontrolü birlikte değerlendirilmelidir.
Authentication kullanıcının kim olduğunu, authorization ise belirli bir eylemi yapıp yapamayacağını belirler. Laravel gate ve policy araçları yetki kontrollerini model veya yetenek etrafında düzenlemeye yardım eder. Resmî authorization rehberi bu iki yaklaşımın kullanımını açıklar.
Controller, Blade görünümü, API ve kuyruk görevi gibi farklı girişlerde aynı yetki kuralını yeniden yazmayın. Policy ile merkezi karar üretin. Arayüzde düğmeyi gizlemek güvenlik değildir; sunucu her istekte yetkiyi doğrulamalıdır.
“Admin her şeyi yapar” modeli başlangıçta kolaydır ancak denetimi zorlaştırır. Kaynak sahipliği, ekip üyeliği, durum, tutar sınırı ve işlem zamanı gibi koşullar gerekebilir. Kritik kararları testlerle belgeleyin.
Laravel service container, sınıf bağımlılıklarını çözmek ve dependency injection uygulamak için kullanılır. Resmî service container belgesi interface–implementation bağlamalarını ve otomatik çözümlemeyi anlatır.
Ödeme, e-posta, dosya depolama veya dış API istemcisini doğrudan new ile her yerde üretmek yerine sözleşme üzerinden enjekte etmek test ve değiştirme esnekliği sağlar. Her sınıf için gereksiz interface oluşturmayın; gerçek alternatif veya sınır olduğunda kullanın.
Eloquent veri erişimini hızlandırır; ilişki, scope, cast ve event özellikleri güçlüdür. Fakat her iş kuralını model içine yığmak büyük ve zor test edilen sınıflar doğurabilir. Model veri davranışını, servis veya action ise birden fazla model ve dış sistemi kapsayan use case’i yönetebilir.
Mass assignment için fillable veya guarded politikasını bilinçli seçin. Kullanıcı isteğini doğrudan create ya da update metoduna aktarmayın; doğrulanmış ve izin verilmiş alanları açıkça seçin. Gizli alanları serialization’dan saklayın.
Liste içinde her kayıt için ilişki sorgusu çalıştırmak performansı hızla bozabilir. Debug araçları ve sorgu loglarıyla N+1 problemini bulun; gerekli ilişkileri eager load edin. Ancak kullanılmayan büyük ilişkileri her zaman yüklemek de maliyetlidir.
Sipariş oluşturma, stok azaltma ve ödeme kaydı gibi birlikte başarılı olması gereken veritabanı işlemlerini transaction içinde yönetin. Dış API çağrısını uzun transaction içinde bekletmek kilit süresini artırabilir; işlem sırasını ve telafi davranışını tasarlayın.
Tekrar gönderilen istekler için idempotency düşünün. Kullanıcı düğmeye iki kez bastığında çift sipariş, ödeme veya e-posta oluşmamalıdır. Unique constraint, işlem anahtarı ve durum makinesi uygulama kontrolünü destekler.
E-posta, rapor üretimi, görüntü işleme veya yavaş dış API çağrısı kullanıcı yanıtını bekletmemeliyse queue uygundur. Job verisi küçük ve yeniden çalıştırılabilir olmalıdır. Başarısız iş, retry, timeout ve maksimum deneme sayısını bilinçli ayarlayın.
Queue worker’ın deploy sonrasında yeni kodu kullanması için kontrollü yeniden başlatma gerekir. Failed jobs izlenmeli; yalnız otomatik retry etmek kök nedeni çözmez. Aynı iş birden çok kez çalışabileceği için yan etkileri idempotent tasarlayın.
Bir iş olayı birden fazla bağımsız tepki doğuruyorsa event yararlı olabilir. Örneğin sipariş tamamlanınca bildirim, analitik ve stok iş akışı tetiklenebilir. Ancak kritik ana iş kuralını görünmez event zincirine gömmek akışı takip etmeyi zorlaştırır.
Observer model yaşam döngüsü için kullanışlıdır; fakat her kaydetmede beklenmedik dış çağrı başlatmamalıdır. Hangi işlemin senkron, hangisinin kuyrukta ve hangisinin başarısızlıkta telafi edileceği açık olmalıdır.
Önce darboğazı ölçün. Sık okunan ve nadir değişen veriyi süreli cache’e almak yararlı olabilir. Cache anahtarı, yaşam süresi, kullanıcı veya tenant ayrımı ve geçersiz kılma yöntemi belirlenmeden eklenen cache eski veya yanlış veri gösterebilir.
Yetkiye bağlı içerikte kullanıcılar arası veri sızıntısına dikkat edin. Cache çalışmadığında uygulamanın davranışını, stampede riskini ve dağıtık kilit ihtiyacını test edin. Cache veri tabanının doğruluk kaynağı değildir.
Blade’in varsayılan escaping davranışı XSS riskini azaltır; ancak ham HTML çıktısı bilinçli kontrol gerektirir. Web middleware grubu CSRF koruması sağlar; API authentication ve CORS ayarları ayrı tasarlanmalıdır. Rate limiting giriş, parola sıfırlama ve pahalı endpoint’lerde uygulanabilir.
APP_DEBUG üretimde kapalı olmalıdır. APP_KEY ve diğer sırlar güvenli saklanmalı, loglara yazılmamalıdır. Paket, PHP ve framework güvenlik güncellemelerini takip edin. Framework korumasını devre dışı bırakırken tehdidi ve telafi kontrolünü belgeleyin.
Feature testleri route, middleware, validation, authorization ve veritabanı davranışını birlikte doğrular. Unit testler saf iş kuralları için hızlı geri bildirim sağlar. Laravel’in resmî test başlangıç belgesi php artisan test ve desteklenen test koşucularını açıklar.
Kritik akışlarda başarılı senaryo kadar yetkisiz kullanıcı, geçersiz veri, tekrar istek, harici servis hatası ve transaction rollback durumunu test edin. Factory ve seeder’ları gerçekçi fakat kişisel veri içermeyen örneklerle kurun.
API yanıtlarında tutarlı durum kodu, hata biçimi ve pagination kullanın. Modeli doğrudan JSON’a dökmek yerine Resource sınıflarıyla dış sözleşmeyi kontrol edin. İç kolon adının değişmesi istemcileri gereksiz etkilememelidir.
Sürümleme ihtiyacını ürün ömrüne göre değerlendirin. Breaking change, kullanımdan kaldırma süresi ve migration rehberi olmadan yayınlanmamalıdır. API token’larına kapsam, son kullanma ve iptal mekanizması ekleyin.
Dağıtım önce CI’da test edilmelidir. Üretimde bağımlılıklar kilit dosyasından, geliştirme paketleri olmadan kurulmalıdır. config, route ve view cache gibi optimizasyonlar mevcut projeye ve sürüme göre uygulanır; deploy sırasında eski cache ile yeni kodun karışmamasına dikkat edilir.
Loglarda ortam, istek kimliği, kullanıcı veya tenant referansı ve olay bağlamı bulunabilir; parola, token veya hassas içerik bulunmamalıdır. Hata oranı, yanıt süresi, kuyruk gecikmesi, başarısız job, veri tabanı bağlantısı ve cache sağlığı izlenmelidir.
Kullanıcıya güvenli ve anlaşılır hata gösterin. Teknik ayrıntıyı yalnız yetkili ekibin erişebildiği sistemde saklayın. Alarm, yalnız ses çıkaran değil sorumlu ve müdahale adımı belli olan sinyal olmalıdır.
Hayır. Eloquent zaten veri erişim yetenekleri sunar. Karmaşık sorgu sınırı, birden fazla veri kaynağı veya bağımsız test gereksinimi varsa repository yararlı olabilir. Sırf şablon olduğu için eklemek gereksiz soyutlama yaratır.
Hayır. Tekrarlanacak veya birden fazla model/dış sistem içeren use case’lerde service ya da action sınıfı faydalıdır. Basit CRUD için frameworkün doğal akışı yeterli olabilir.
İş kullanıcı yanıtını bekletiyorsa, dış servis nedeniyle dalgalıysa veya yeniden denenmesi gerekiyorsa queue düşünün. İşin tekrar çalışmaya dayanıklı ve izlenebilir olması gerekir.
İyi Laravel mimarisi, en fazla design pattern kullanan değil; iş akışını görünür tutan, güvenlik kararlarını merkezi uygulayan ve üretimde ölçülebilen mimaridir. Frameworkün hızını korurken bağımlılıkları, yan etkileri ve yetkileri açık sınırlarla yöneten proje uzun vadede daha kolay gelişir.
Bu rehber, yeni bir Laravel projesini “hangi klasöre ne koymalıyım?” sorusundan üretim ortamına kadar ele alır. Sürüm seçimi, controller sınırları, service container, Form Request, policy, Eloquent, queue, test ve deployment adımlarını tek akışta birleştirir.
Laravel projesine başlamadan önce ne netleşmeli?
Önce uygulamanın kullanıcılarını, temel iş akışlarını, veri sahipliğini ve yüksek riskli işlemlerini yazın. Bir yönetim paneli, API, pazar yeri veya içerik sitesi aynı mimari önceliklere sahip değildir. Kullanıcı sayısından önce veri tutarlılığı, yetki modeli, dış servisler ve bakım sorumluluğu anlaşılmalıdır.
Minimum uygulanabilir kapsamı belirleyin. Kimlik doğrulama, ödeme, dosya yükleme, e-posta, arama, raporlama ve çoklu kiracı gibi özelliklerin hangilerinin ilk sürümde gerekli olduğunu ayırın. Mimari, gelecekte olabilecek her şeyi değil; bugün bilinen riskleri anlaşılır sınırlarla yönetmelidir.
Laravel ve PHP sürümü nasıl seçilir?
Resmî Laravel dokümantasyonunda projenizin ana sürümünü seçerek PHP gereksinimini, yükseltme notlarını ve özellik davranışını kontrol edin. “En yeni” sürümü körlemesine seçmek yerine paket uyumu, barındırma desteği ve bakım takvimini değerlendirin.
composer.json içinde PHP ve paket sürüm kurallarını açıkça tanımlayın; composer.lock dosyasını uygulama deposunda saklayın. Geliştirme, CI ve üretimde aynı ana PHP sürümünü kullanmaya çalışın. Güncellemeleri küçük, test edilebilir paketler hâlinde yapın.
Varsayılan Laravel dizinleri nasıl düşünülmeli?
app dizini uygulama kodunun ana alanıdır; routes giriş noktalarını, config yapılandırma tanımlarını, database migration ve seed dosyalarını, resources görünüm ve ön uç kaynaklarını, tests ise otomatik testleri barındırır. public, web sunucusunun belge kökü olmalıdır.
storage ve bootstrap/cache için yazma izinleri gerekir; fakat geniş ve kontrolsüz dosya izinlerinden kaçının. .env, kaynak kodu ve loglar doğrudan web üzerinden erişilebilir olmamalıdır. Klasörleri yalnız estetik için çoğaltmak yerine sorumluluk büyüdükçe ayırın.
Route ve controller sınırı
Route, HTTP yöntemi ve URL’yi doğru handler’a bağlar. Controller; isteği alır, doğrulama ve yetki akışını tetikler, uygulama servisini çağırır ve yanıt üretir. Büyük SQL sorguları, karmaşık fiyat hesapları ve dış servis ayrıntıları controller içinde birikmemelidir.
Resource controller ve route model binding tekrar eden kodu azaltabilir. Ancak otomatik model bağlama yetkilendirme değildir. Bir kaydın URL’den bulunması, mevcut kullanıcının onu görme veya değiştirme hakkı olduğu anlamına gelmez.
İnce controller ne demektir?
İnce controller hiç mantık içermeyen controller değildir. HTTP’ye ait kararları tutar; tekrar kullanılacak iş kurallarını action veya service sınıflarına yönlendirir. Aşırı katman üretmeden, test ve değişiklik ihtiyacına göre sınır çizin.
Validation ve Form Request
Girdi doğrulama; alanın zorunlu olup olmadığı, biçim, boyut ve ilişkili kuralları kontrol eder. Karmaşık isteklerde Form Request, doğrulama ile isteğe özel authorization kontrolünü ayrı bir sınıfta toplar. Laravel’in validation belgesi kuralları ve hata davranışını açıklar.
Doğrulanmış veri, güvenilir iş kararı anlamına gelmez. “Tutar sayıdır” biçim doğrulamasıdır; kullanıcının bu siparişe indirim uygulama hakkı iş kuralıdır. İkisini ayrı test edin. Dosya yüklemede MIME, boyut, içerik, saklama alanı ve erişim kontrolü birlikte değerlendirilmelidir.
Authentication ve authorization ayrımı
Authentication kullanıcının kim olduğunu, authorization ise belirli bir eylemi yapıp yapamayacağını belirler. Laravel gate ve policy araçları yetki kontrollerini model veya yetenek etrafında düzenlemeye yardım eder. Resmî authorization rehberi bu iki yaklaşımın kullanımını açıklar.
Controller, Blade görünümü, API ve kuyruk görevi gibi farklı girişlerde aynı yetki kuralını yeniden yazmayın. Policy ile merkezi karar üretin. Arayüzde düğmeyi gizlemek güvenlik değildir; sunucu her istekte yetkiyi doğrulamalıdır.
Sahiplik ve rol tek başına yeterli olmayabilir
“Admin her şeyi yapar” modeli başlangıçta kolaydır ancak denetimi zorlaştırır. Kaynak sahipliği, ekip üyeliği, durum, tutar sınırı ve işlem zamanı gibi koşullar gerekebilir. Kritik kararları testlerle belgeleyin.
Service container ve dependency injection
Laravel service container, sınıf bağımlılıklarını çözmek ve dependency injection uygulamak için kullanılır. Resmî service container belgesi interface–implementation bağlamalarını ve otomatik çözümlemeyi anlatır.
Ödeme, e-posta, dosya depolama veya dış API istemcisini doğrudan new ile her yerde üretmek yerine sözleşme üzerinden enjekte etmek test ve değiştirme esnekliği sağlar. Her sınıf için gereksiz interface oluşturmayın; gerçek alternatif veya sınır olduğunda kullanın.
Eloquent modelleri nasıl sınırlandırılmalı?
Eloquent veri erişimini hızlandırır; ilişki, scope, cast ve event özellikleri güçlüdür. Fakat her iş kuralını model içine yığmak büyük ve zor test edilen sınıflar doğurabilir. Model veri davranışını, servis veya action ise birden fazla model ve dış sistemi kapsayan use case’i yönetebilir.
Mass assignment için fillable veya guarded politikasını bilinçli seçin. Kullanıcı isteğini doğrudan create ya da update metoduna aktarmayın; doğrulanmış ve izin verilmiş alanları açıkça seçin. Gizli alanları serialization’dan saklayın.
N+1 sorgu ve eager loading
Liste içinde her kayıt için ilişki sorgusu çalıştırmak performansı hızla bozabilir. Debug araçları ve sorgu loglarıyla N+1 problemini bulun; gerekli ilişkileri eager load edin. Ancak kullanılmayan büyük ilişkileri her zaman yüklemek de maliyetlidir.
Transaction ve eşzamanlılık
Sipariş oluşturma, stok azaltma ve ödeme kaydı gibi birlikte başarılı olması gereken veritabanı işlemlerini transaction içinde yönetin. Dış API çağrısını uzun transaction içinde bekletmek kilit süresini artırabilir; işlem sırasını ve telafi davranışını tasarlayın.
Tekrar gönderilen istekler için idempotency düşünün. Kullanıcı düğmeye iki kez bastığında çift sipariş, ödeme veya e-posta oluşmamalıdır. Unique constraint, işlem anahtarı ve durum makinesi uygulama kontrolünü destekler.
Queue ne zaman kullanılmalı?
E-posta, rapor üretimi, görüntü işleme veya yavaş dış API çağrısı kullanıcı yanıtını bekletmemeliyse queue uygundur. Job verisi küçük ve yeniden çalıştırılabilir olmalıdır. Başarısız iş, retry, timeout ve maksimum deneme sayısını bilinçli ayarlayın.
Queue worker’ın deploy sonrasında yeni kodu kullanması için kontrollü yeniden başlatma gerekir. Failed jobs izlenmeli; yalnız otomatik retry etmek kök nedeni çözmez. Aynı iş birden çok kez çalışabileceği için yan etkileri idempotent tasarlayın.
Event, listener ve observer kullanımı
Bir iş olayı birden fazla bağımsız tepki doğuruyorsa event yararlı olabilir. Örneğin sipariş tamamlanınca bildirim, analitik ve stok iş akışı tetiklenebilir. Ancak kritik ana iş kuralını görünmez event zincirine gömmek akışı takip etmeyi zorlaştırır.
Observer model yaşam döngüsü için kullanışlıdır; fakat her kaydetmede beklenmedik dış çağrı başlatmamalıdır. Hangi işlemin senkron, hangisinin kuyrukta ve hangisinin başarısızlıkta telafi edileceği açık olmalıdır.
Cache stratejisi
Önce darboğazı ölçün. Sık okunan ve nadir değişen veriyi süreli cache’e almak yararlı olabilir. Cache anahtarı, yaşam süresi, kullanıcı veya tenant ayrımı ve geçersiz kılma yöntemi belirlenmeden eklenen cache eski veya yanlış veri gösterebilir.
Yetkiye bağlı içerikte kullanıcılar arası veri sızıntısına dikkat edin. Cache çalışmadığında uygulamanın davranışını, stampede riskini ve dağıtık kilit ihtiyacını test edin. Cache veri tabanının doğruluk kaynağı değildir.
Güvenlikte Laravel varsayımları
Blade’in varsayılan escaping davranışı XSS riskini azaltır; ancak ham HTML çıktısı bilinçli kontrol gerektirir. Web middleware grubu CSRF koruması sağlar; API authentication ve CORS ayarları ayrı tasarlanmalıdır. Rate limiting giriş, parola sıfırlama ve pahalı endpoint’lerde uygulanabilir.
APP_DEBUG üretimde kapalı olmalıdır. APP_KEY ve diğer sırlar güvenli saklanmalı, loglara yazılmamalıdır. Paket, PHP ve framework güvenlik güncellemelerini takip edin. Framework korumasını devre dışı bırakırken tehdidi ve telafi kontrolünü belgeleyin.
Test stratejisi
Feature testleri route, middleware, validation, authorization ve veritabanı davranışını birlikte doğrular. Unit testler saf iş kuralları için hızlı geri bildirim sağlar. Laravel’in resmî test başlangıç belgesi php artisan test ve desteklenen test koşucularını açıklar.
Kritik akışlarda başarılı senaryo kadar yetkisiz kullanıcı, geçersiz veri, tekrar istek, harici servis hatası ve transaction rollback durumunu test edin. Factory ve seeder’ları gerçekçi fakat kişisel veri içermeyen örneklerle kurun.
API tasarımı ve hata sözleşmesi
API yanıtlarında tutarlı durum kodu, hata biçimi ve pagination kullanın. Modeli doğrudan JSON’a dökmek yerine Resource sınıflarıyla dış sözleşmeyi kontrol edin. İç kolon adının değişmesi istemcileri gereksiz etkilememelidir.
Sürümleme ihtiyacını ürün ömrüne göre değerlendirin. Breaking change, kullanımdan kaldırma süresi ve migration rehberi olmadan yayınlanmamalıdır. API token’larına kapsam, son kullanma ve iptal mekanizması ekleyin.
Üretim deployment kontrol listesi
Dağıtım önce CI’da test edilmelidir. Üretimde bağımlılıklar kilit dosyasından, geliştirme paketleri olmadan kurulmalıdır. config, route ve view cache gibi optimizasyonlar mevcut projeye ve sürüme göre uygulanır; deploy sırasında eski cache ile yeni kodun karışmamasına dikkat edilir.
- Bakım veya kademeli yayın planını hazırlayın.
- Kodu ve bağımlılıkları kurup cache’leri kontrollü oluşturun.
- Migration’ın kilit, süre ve geri dönüş etkisini değerlendirin.
- Queue worker’ları yeni sürüme güvenli biçimde taşıyın.
- Sağlık kontrolü, log ve temel metrikleri doğrulayın.
- Hata oranı artarsa rollback veya ileri düzeltme uygulayın.
İzleme ve hata yönetimi
Loglarda ortam, istek kimliği, kullanıcı veya tenant referansı ve olay bağlamı bulunabilir; parola, token veya hassas içerik bulunmamalıdır. Hata oranı, yanıt süresi, kuyruk gecikmesi, başarısız job, veri tabanı bağlantısı ve cache sağlığı izlenmelidir.
Kullanıcıya güvenli ve anlaşılır hata gösterin. Teknik ayrıntıyı yalnız yetkili ekibin erişebildiği sistemde saklayın. Alarm, yalnız ses çıkaran değil sorumlu ve müdahale adımı belli olan sinyal olmalıdır.
Sık sorulan sorular
Laravel’de repository pattern şart mı?
Hayır. Eloquent zaten veri erişim yetenekleri sunar. Karmaşık sorgu sınırı, birden fazla veri kaynağı veya bağımsız test gereksinimi varsa repository yararlı olabilir. Sırf şablon olduğu için eklemek gereksiz soyutlama yaratır.
Her işlem service sınıfında mı olmalı?
Hayır. Tekrarlanacak veya birden fazla model/dış sistem içeren use case’lerde service ya da action sınıfı faydalıdır. Basit CRUD için frameworkün doğal akışı yeterli olabilir.
Laravel projesi ne zaman queue kullanmalı?
İş kullanıcı yanıtını bekletiyorsa, dış servis nedeniyle dalgalıysa veya yeniden denenmesi gerekiyorsa queue düşünün. İşin tekrar çalışmaya dayanıklı ve izlenebilir olması gerekir.
Mimari kontrol listesi
- Laravel ve PHP sürümü ile paket uyumu belgeli mi?
- Controller, iş kuralı ve veri erişimi sınırları anlaşılır mı?
- Validation ile authorization ayrı ve test edilmiş mi?
- Mass assignment, XSS, CSRF, sır ve dosya yükleme riskleri kontrol edildi mi?
- Queue işleri retry, timeout ve idempotency açısından güvenli mi?
- N+1 sorgu, cache ve transaction davranışı ölçüldü mü?
- Deployment, migration, worker restart, izleme ve rollback planı hazır mı?
İyi Laravel mimarisi, en fazla design pattern kullanan değil; iş akışını görünür tutan, güvenlik kararlarını merkezi uygulayan ve üretimde ölçülebilen mimaridir. Frameworkün hızını korurken bağımlılıkları, yan etkileri ve yetkileri açık sınırlarla yöneten proje uzun vadede daha kolay gelişir.