v1 modül alan haritası

Eski planın referansı

Amaç v1 kodunu iş gözüyle haritalamaktır. Her modülün ayrıntılı görevi için Modül haritası sayfasına bakın; burada sadece eski plandaki alanı ve tartışmalı noktası bulunur.

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ı: v1 mesajlaşma analizi.

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.

Bu soru çalışan v2'de orders domain'inin ortak sipariş ve ödeme belgelerinin sahibi olması, diğer alanların yayımlanan servislerden okuması yönünde çözüldü. Geçiş boyunca v1 de aynı belgelerin yaşam döngüsünü işlemeye devam eder.

Eski planın açık soruları

Aşağıdaki maddeler ilk alan çalışmasında açık bırakılmıştı. Güncel v2 kararları yanında belirtilmiştir:

order nereye ait? v2'de orders domain'i var; çapraz okumalar servis sınırlarından geçiyor.
admin üç ayrı işi taşıyor: v2'de müşteri ve personel parties, finans görünümü finance, operasyonel yönetim ilgili domain'lere dağılıyor. Bütün v1 admin uçları henüz taşınmadı.
officer iki işi taşıyor: personel yönetiminin bir bölümü parties/staff altında; saha/teslimat yüzeylerinin çoğu hâlâ v1'de.
report ortak mı olmalı? v2'de ortak bir domain değildir. Her rapor cevapladığı alan sorusunun altında yaşar; yeniden kurma işlemleri ops altındadır.
seller, tedarikçi kartı olarak lojistik, ödeme takvimi/vergi sorgusu olarak muhasebe tarafını taşıyor.
area nerede olmalı? Ülke/şehir referansı core/area, kapsama kuralı logistics/zones altında ayrıldı.
price-analytics nerede olmalı? Yeni mobilin fiyat yüzeyi catalog altında; v1 admin analitiğinin tamamı taşınmış değil.
İki paralel stok sistemi: v2 ortak stockEntries/stockExits belgelerini kullanırken alım ve sayım için kendi koleksiyonlarını ekledi. Platform genelindeki geçiş tamamlanmış değildir.
Yoğun döngüsel modül bağımlılığı: v2 domain sahipliği ve yayımlanan servis kuralıyla azaltılıyor; geçiş tamamlanmadığı için iki servis arasındaki veri bağı devam ediyor.
HksInvoiceTracker Prisma modeli şemada var ama kodda hiçbir yerde kullanılmıyor — ölü model mi, rezerve alan mı netleşmeli.

Bu sayfa v1 analizi olarak korunur; yeni kararlar v2 mimarisi ve geçiş ve veri sahipliği sayfalarında tutulur.