Geçiş ve veri sahipliği

v2, v1'in yerine bir anda geçen bağımsız bir sistem değildir. İki servis aynı veritabanlarını ve oturumu paylaşır; ekranlar ve akışlar adım adım v2'ye alınır.

Uç türleri

Taşınan bir uç “iyileştirilirken” çalışan istemcinin cevabı sessizce değiştirilemez. Yeni sözleşme gerekiyorsa yeni bir uç açılır. Bilinçli uyumluluk istisnaları kod tabanında tarihli kararla tutulur.

Taşınan uçlardaki iki genel fark yalnız hatalı isteği etkiler:

• DTO'da tanımsız parametre sessizce atılmaz, 400 döner.
• Hata zarfı v1'den farklıdır: { statusCode, path, timestamp, message }.

Bugünkü geçiş yüzeyi

Yol biçimine göre üç yüzey yan yana bulunur:

Yeni yüzeyler arasında:

• /finance/*: özet, cari, kasa ve banka, tahsilat, havale, POS ve fatura
• /logistics/*: stok, alım, sayım ve depo
• /orders/buyer/*: yeni mobil sepet, satın alma, sipariş, ödeme, iade ve teslimat
• /parties/*: müşteri, personel, grup, alıcı profil/adres ve POST /parties/buyer/sign-up
• /comms/buyer/*: alıcı mesajı, bildirimi ve içerik
• /catalog/buyer/*: yeni mobil katalog ve fiyat yüzeyi

bulunur.

Bu liste bütün controller'ların Swagger dökümü değildir; geçiş sınırını anlatır. workflow, tedarik/satıcı portalı, birçok officer/admin operasyonu, BigQuery migration ve zamanlanmış işler gibi geniş yüzeyler v1'de kalır.

Prisma şemasının sahibi

haljet-api/prisma/schema.prisma kaynak şemadır. v2'deki dosya onun aynasıdır:

• v2 migration üretmez veya çalıştırmaz.
• Yeni alan önce v1 şemasına ve migration'ına eklenir.
• Ardından şema v2'ye kopyalanır ve SHA kaydı güncellenir.
• npm run schema:check iki dosyanın aynı olduğunu doğrular.

v1 desteği sonlanana kadar ilişkisel şema sahipliği v2'ye geçmez. Ayna belirli bir v1 commit'ine bağlıdır; iki çalışma kopyısı karşılaştırılırken önce schema:check sonucuna bakılmalıdır.

MongoDB sahipliği

v2 Mongo şemaları çoğu zaman ortak v1 belgesinin yalnızca okunan alt kümesini tanımlar. Ortak koleksiyonlara yazarken Mongoose save() kullanılmaz; tanınmayan alanların düşmemesi için ham koleksiyon işlemleri ve açık alan listeleri kullanılır.

“Tek sahip”, tek yazma sahibi demektir. Başka domain'in koleksiyonu genel olarak yayımlanan servis üzerinden okunur; lojistiğin fatura ve içe aktarma şemalarını stok eşleştirmesi için salt okuma amacıyla kaydetmesi açık bir istisnadır.

İki servisin birlikte yazdığı başlıca koleksiyonlar:

• sipariş ve ödeme: buyerOrders, payments
• mobil iade ve sorun: buyerOrderReturns, returnMediaUploads, buyerOrderIssues, orderSurveyResponses
• iletişim: conversations, messages, notifications
• katalog talebi: productRequests
• stok: stockEntries, stockExits
• HKS: kunyeMelt, kunyeMeltRun
• hesap kaydı: userLogs
• cari defteri: accountTransactions
• rapor: productSalesReports, productPurchaseReports

Cari geçişi iki veri katmanına birden yazar: v1 ve v2 kendi yollarından Mongo accountTransactions satırı oluşturabilir ve MySQL FinancialAccount.balance alanını güncelleyebilir. LedgerService, yalnızca v2 içindeki cari yazmalarının tek kapısıdır; platform genelinde v1 yazma yolunu ortadan kaldırmaz.

v2'nin sahip olduğu yeni koleksiyonlar:

• lojistik: stockPurchases, stockCounts, stockCodeCounters, stockSupplierReturns
• fatura içe aktarma ve kırılım: invoiceImports, invoiceImportCandidates, invoiceBreakdowns, invoiceBreakdownFailures
• finans: cariPendingEntries, transferMoneyFailures

Şema sahibi ile yazanın ayrıldığı tablolar

Kasa ve Banka tabloları Prisma şemasında v1 tarafından tanımlanır ve migration'ları v1'den gelir. Ancak MoneyAccount, MoneyMovement, Expense ve PayablePayment kayıtlarını yalnız v2 yazar.

Bu ayrım geçiş dönemine özeldir:

• şema sahibi migration'ın nereden üretildiğini,
• veri sahibi iş kuralının ve yazma kapısının hangi serviste olduğunu

belirtir.

Ortak oturum

İki servis de erişim ve yenileme jetonu üretir ve doğrular. ACCESS_TOKEN_SECRET ile REFRESH_TOKEN_SECRET aynı olmalı; jeton gövdesindeki sub, role ve permissions anlamı korunmalıdır.

User.refreshToken tek ortak hash alanıdır. Bu nedenle oturum biçimini tek serviste değiştirmek diğer servisteki oturumu da bozar; kimlik değişiklikleri iki kod tabanında birlikte ele alınır.

Sipariş ve kart ödeme sınırı

Yeni mobil uygulamanın sipariş akışı iki servisten geçer:

1. v2 sepeti fiyatlandırır ve v1 biçimindeki buyerOrders belgesini yazar.
2. Kart seçilirse v2, v1 biçimindeki bekleyen payments kaydını oluşturur.
3. Ödeme sağlayıcısının tek geri çağrı adresi v1'i gösterir.
4. v1 siparişi ödendi yapar ve kendi hazırlık/fatura zincirini devam ettirir.
5. Mobil istemci ödeme sonucunu v2'den sorgular.

İki servis aynı kullanıcı veya sipariş üzerinde eş zamanlı yazabildiği için v2 kilit anahtarları v1'in MurLock biçimiyle ve aynı Redis üzerinde üretilir.

Kuyruk ve yan etkiler

Ortak kuyruk işinin v1 tarafından işlenmesi gerekiyorsa v2, v1'in kuyruk adı ve önekini kullanır. v2'nin kendi satış raporu kuyruğu ise aynı adlı v1 işlerini tüketmemek için ayrı önek taşır.

Yazma sonrası bildirim veya rapor gibi yan etkiler ana finansal yazmayı geri almamalıdır. v2'de bu zincir çoğunlukla olay yayıcı yerine doğrudan servis çağrılarıyla görünür tutulur.

Bilerek taşınmayan davranışlar

BigQuery izleme ve Gemini sipariş notu ayrıştırma v2'nin kendi ödendi yaptığı akışlara taşınmamıştır. Kart siparişinin geri çağrısını v1 işlediği durumda bu v1 yan etkileri yine çalışır; v2'nin havale veya cari üzerinden ödendi yaptığı siparişte çalışmaz.

Bu ayrım geçiş tamamlanmış gibi gizlenmez; istemci veya rapor davranışı değerlendirilirken siparişin hangi servis zincirinden geçtiği dikkate alınır.