Alan haritası

Bugünkü modüller hangi alana giriyor?

Bu sayfa bugün src/modules altında duran 27 modülü, hedeflenen dört alana (v2 nedir?) göre sınıflandırır. Amaç kod değiştirmek değil, mevcut yapıyı yeni bir gözle haritalamak. Her modülün ayrıntılı görevi için Modül haritası sayfasına bakın; burada sadece hangi alana ait olduğu ve varsa tartışmalı noktası var.

Satış

"Satış" burada bir insan satış ekibini değil, self-servis mobil vitrini ifade ediyor — alıcı kendi kendine buyer (mobil uygulama) üzerinden sipariş veriyor, aradan satış yapan biri yok. Satıştan doğan sorunlarla (iade, şikayet, sorun bildirimi) admin'in zaten sahip olduğu CRM/destek fonksiyonu ilgileniyor — bu yüzden "destek" ayrı bir alan değil, admin'in içinde.

Bu alanın müşteriyle mesajlaşma boyutu (bugün message modülünde yaşıyor) ayrıca detaylandırıldı: Satış alanı detayı.

Modül	Alana neden giriyor	Not
`catalog`	Ürün, kategori, fiyat, arama — vitrin	HKS ürün kodu ve depo fiyatı lojistik tarafına da dokunuyor
`basket`	Alıcının sepeti	—
`purchase`	Sepetten sipariş oluşturma (checkout)	Oluşturduğu belge `order`'a yazılıyor
`buyer`	Alıcı profili, adres	`buyer/warehouse` ekstre görünümü muhasebe verisini gösteriyor
`buyer-group`	Alıcı segmentasyonu (ciro, sipariş adedi)	—
`post`	Vitrin içerik: slider, banner, akademi	—
`price-analytics`	Piyasa fiyat analitiği, ticker	Diğer modüllere bağımlı değil; admin analitiğine de sayılabilir

Lojistik

Tedarik (seller/procurement) burada da bir insan satın alma ekibinin talebiyle değil, talep odaklı (pull) çalışıyor: depo ekibi, satıştan oluşan "alınacaklar listesi"ne göre satıcıdan tedarik kararı veriyor. Yani tedarik, satış verisine tepki veren bir lojistik fonksiyonu.

Modül	Alana neden giriyor	Not
`warehouse`	Depo tanımı, kapsama alanı, araç, istatistik	Eski stok-in/out da burada yaşıyor
`stock`	Yeni FIFO stok girişi/çıkışı	`warehouse` içindeki eski stok sistemiyle paralel çalışıyor — bkz. açık sorular
`transfer`	Teslimat, araç seferi, kapıda tahsilat	—
`procurement`	Satıcının tedarik talebi	Talep, satıştan oluşan "alınacaklar listesi"ne göre depo ekibince tetikleniyor
`seller`	Tedarikçi kartı	Ödeme takvimi ve vergi sorgusu muhasebe tarafına dokunuyor
`area`	Ülke, il, ilçe, mahalle	Adres olarak satışa, kapsama alanı olarak lojistiğe hizmet ediyor

Muhasebe

Modül	Alana neden giriyor	Not
`financial`	Cari bakiye, hareket defteri	—
`invoice`	Giden/gelen e-fatura kaydı	—
`payment`	Ödeme sağlayıcı entegrasyonları (PayTR, Paywall, MagicPay)	—

Admin

Modül	Alana neden giriyor	Not
`admin`	Alıcı CRM, yetkili atama, platform ayarları	Üç ayrı iş tek modülde bir arada — bkz. açık sorular
`officer`	Yetkili/personel yönetimi, konum, atama	Saha/teslimat operasyonu tarafı lojistiğe yakın — bkz. açık sorular

Ortak / çekirdek

Aşağıdakiler hiçbir alana özgü değil; hepsi tarafından kullanılıyor. Alan bazlı yeniden yapılanmadan bağımsız, ortak katman olarak kalması beklenir.

Modül / klasör	Görevi
`auth`, `user`	Kimlik, hesap
`message`, `notification`	Sohbet ve bildirim altyapısı
`ai`	Doğal dil asistanı
`static`	Politika sayfaları
`report`	Tüm alanlardan okuyan raporlama katmanı
`workflow`	Depo bazlı genel iş takip panosu (alana özgü değil)
`izibiz`, `hks`, `mail`, `sms`, `meilisearch`, `bigquery`, `firebase`, `gemini`	Dış sistem sarmalayıcıları
`common`, `config`, `prisma`, `i18n`	Platform altyapısı

Özel durum: order

order hiçbir alana tam olarak sığmıyor — çünkü sipariş, satışın sonucu, lojistiğin girdisi ve muhasebenin tetikleyicisi aynı anda. Bugünkü kodda da bunu yansıtır şekilde en çok modülü import eden, en çok modül tarafından import edilen modül order.

Hedef yapı planlanırken order'ın tek bir alana taşınıp taşınmayacağı, yoksa dört alanın da okuyup yazdığı ortak bir "sipariş çekirdeği" olarak mı kalacağı ayrıca karara bağlanmalı.

Açık sorular

Hedef yapı planına geçmeden önce netleşmesi gereken noktalar:

order nereye ait? Tek alana taşınacak mı, yoksa ortak çekirdek olarak mı kalacak? (yukarıya bakın)
admin üç ayrı işi taşıyor: alıcı CRM, yetkili ataması, platform ayarları (şirket tipleri, test siparişi). Bunlar ayrışacak mı, tek "admin" alanında mı kalacak?
officer, personel yönetimi (admin) ile saha/teslimat operasyonu (lojistik) arasında bölünmüş durumda.
report, tanımı gereği tüm alanlardan okuyor; tek bir alana yazılamaz — muhtemelen ortak katman olarak kalmalı, alan bazlı alt sayfalar üretebilir.
seller, tedarikçi kartı olarak lojistik, ödeme takvimi/vergi sorgusu olarak muhasebe tarafını taşıyor.
area, adres ihtiyacı (satış/admin) ile kapsama alanı/bölge (lojistik) arasında paylaşılıyor.
price-analytics bağımsız duruyor; satışın fiyat zekası mı, admin'in analitik katmanı mı olacağı netleşmeli.
İki paralel stok sistemi var: warehouse içindeki eski stok-in/out ile stock modülündeki yeni FIFO sistemi aynı anda çalışıyor. v2'de birleştirilmesi düşünülmeli.
Yoğun döngüsel modül bağımlılığı (order, officer, warehouse, buyer, transfer, financial, payment, catalog, admin birbirini forwardRef ile çağırıyor) alan sınırları çizilirken kırılması gereken bir engel. Her sınır değişikliği cold-boot ile doğrulanmalı (tsc/eslint döngüsel kırılmaları yakalamıyor).
HksInvoiceTracker Prisma modeli şemada var ama kodda hiçbir yerde kullanılmıyor — ölü model mi, rezerve alan mı netleşmeli.

Bu sorular, hedef yapı planı (bkz. v2 nedir?) yazılırken tek tek karara bağlanacak.