Sistem Analizi Raporu

Versiyon 3.0 | Tarih: 2025-11-29 | Analiz Motoru: Gemini

Yönetici Özeti: Bilinmesi Gerekenler

Sistem, **"Split-Brain" (Bölünmüş Beyin)** olarak adlandırabileceğimiz temel bir mimari çelişki yaşamaktadır. Dökümantasyon, kullanıcıların **merkezi** bir sistemde olduğunu söylerken, kod her bir kiracı (tenant) için **ayrı bir kullanıcı tablosu** oluşturmaktadır. Bu durum, hem geliştirme sürecinde kafa karışıklığına hem de ciddi veri bütünlüğü ve güvenlik risklerine yol açmaktadır. Raporun devamında bu çelişkinin kanıtları ve çözüm stratejileri sunulmaktadır.

Ana Keşif: Döküman ve Kod Arasındaki Çelişki

Döküman Ne Diyor?

CLAUDE.md dosyasına göre, users, roles, ve permissions tabloları tüm kiracılar için **ortaktır** ve merkezi veritabanında yer alır.

  • Veri Bütünlüğü
  • Tekil Kullanıcı Yönetimi
  • Merkezi Yetkilendirme

Kod Ne Yapıyor?

Veritabanı migration dosyaları incelendiğinde, create_users_table.php dosyasının hem **merkezi** hem de **kiracı** klasörlerinde olduğu görülmüştür.

  • database/migrations/ ➔ users tablosu var
  • database/migrations/tenant/ ➔ users tablosu var
  • **Sonuç:** Her kiracının kendi izole kullanıcı tablosu var.

Bu Çelişkinin Doğurduğu Riskler

Geliştirici Kafa Karışıklığı

Dökümana güvenen bir geliştirici, kullanıcı işlemlerini merkezi varsayarak kod yazar ve farkında olmadan ciddi hatalara yol açar. Bu, geliştirme sürecini yavaşlatır ve güvenilirliğini azaltır.

Model Belirsizliği

app/Models/User.php modeli, hem merkezi hem de kiracı veritabanındaki `users` tablolarına aynı anda hizmet edemez. Bu durum, hangi veritabanına bağlanacağını şaşırmasına ve beklenmedik hatalara neden olur.

Kimlik Doğrulama Kaosu

Bir kullanıcı giriş yapmaya çalıştığında sistem hangi `users` tablosunu kullanmalı? Merkezi mi, kiracınınkini mi? Bu belirsizlik, kullanıcıların sisteme giriş yapamamasına veya yanlış yetkilerle işlem yapmasına neden olabilir.

Çözüm Stratejisi: Netliğe Giden Yol

Sistemin sağlığı ve geleceği için bu mimari çelişkinin çözülmesi şarttır. İki olası yol vardır, ancak biri şiddetle tavsiye edilir:

Yol A: Merkezi Mimarıyı Benimse (Tavsiye Edilen)

Kod, dökümantasyona uydurulur. Bu, modern SaaS uygulamaları için en iyi pratiktir.

  1. Kiracı migration klasöründen (/tenant/) create_users_table.php ve ilgili migration'lar **kaldırılır.**
  2. User, Role, Permission gibi tüm merkezi modellerin her zaman protected $connection = 'central'; kullanması **garanti altına alınır.**
  3. Sistem, tek bir merkezi kullanıcı tablosundan çalışacak şekilde düzenlenir.

Yol B: Kiracıya Özel Mimarıyı Benimse

Dökümantasyon, koda uydurulur. Bu, her kiracının tamamen izole olmasını gerektiren senaryolarda geçerlidir.

  1. CLAUDE.md dökümanı, kullanıcıların kiracıya özel olduğunu belirtecek şekilde **güncellenir.**
  2. app/Models/User.php gibi merkezi modeller yerine, kiracı context'inde çalışacak app/Models/Tenant/User.php gibi yeni modeller oluşturulur.
  3. Sistemin kimlik doğrulama mekanizması, kiracıya özel kullanıcıları tanıyacak şekilde yeniden yapılandırılır.

Diğer Bulgular (İkincil Öncelik)

"Şişman Model" Sorunu

User modeli, sadece "Muzibu" kiracısına özel işlevler içeriyor. Bu, modelin temizliğini ve bakımını zorlaştırıyor. Bu mantık, Muzibu modülü içine taşınmalıdır.

Riskli Dosya İzinleri

Yeni kiracı klasörleri oluşturulurken dosya izin hatalarının @ operatörü ile gizlenmesi, olası sorunların fark edilmesini engeller. Bu operatör kaldırılmalı ve hatalar loglanmalıdır.

"Şişman Kontrolcü"

DebugDashboardController gibi kontrolcüler, içinde karmaşık veri sorguları barındırıyor. Bu sorgular, kodun okunabilirliğini azaltır ve test edilmesini zorlaştırır. İş mantığı, servis katmanlarına taşınmalıdır.