v1 mesajlaşma analizi

v1 modül alan haritası'ndaki eski Satış alanı (catalog, basket, purchase, buyer, buyer-group, post, price-analytics) self-servis vitrini kapsıyordu. Bu sayfa ek bir boyutu detaylandırır: v1'de message modülünde yaşayan müşteri ile satışa dair mesajlaşma.

v2 buyer yüzeyi

Yeni BUYER uygulamasında konuşma listesi, mesaj okuma/yazma, destek konuşması, düzenleme, silme, tepki, iletme ve tekil mesaj okuma uçları /comms/buyer/* altında yaşar.

v2, ortak conversations, messages ve notifications koleksiyonlarına v1 belge biçimini koruyarak yazar. Canlı mesaj görünümü Firebase Realtime Database üzerindedir; temsilci hatırlatma işini geçiş boyunca v1 kuyruğu işler. Bu buyer yüzeyinin varlığı, aşağıda anlatılan v1 panel kuyruğu ve depo kapsamı eksiklerini kendiliğinden çözmez.

Mesajlaşma mimarisi: context registry

message modülü tek başına hangi domain'e ait olduğunu bilmiyor — bunun yerine bir resolver registry kullanıyor: her domain, kendi ConversationContextType değeri için ConversationContextRegistry'ye bir resolver kaydediyor (onModuleInit ile). Bir konuşma başlatıldığında message modülü ilgili resolver'ı çağırıp yetkilendirme + katılımcı listesini alıyor, kendi modülünü domain'e import etmeden. Bu, döngüsel bağımlılığı önleyen iyi bir tasarım — v1 modül alan haritası'ndaki yoğun forwardRef sorununun tam tersi bir çözüm.

ConversationContextType kapsamı

Eksiklikler

• ORDER context'i tamamen ölü. Bir alıcının belirli bir siparişi hakkında mesajlaşabileceği bir yol yok — sadece genel SUPPORT hattı var. Sipariş bazlı mesajlaşma (ör. "bu ürün eksik geldi", "teslimat ne zaman") bugün ya SUPPORT'a düşüyor ya da hiç yapılamıyor.
• ProductRequest (katalog: "bu ürünü ekleyin" talebi) ile PRODUCT konuşması aynı isimde ama farklı iki şey, sadece servis çağrısı seviyesinde bağlı: product-request-buyer.service.ts, talep oluşunca PRODUCT konuşmasına bir sistem mesajı yazıyor (getOrCreateProductConversation + createSystemMessage) — ama ProductRequest şemasında conversationId gibi kalıcı bir alan yok. Konuşmayı bulmak için her seferinde alıcı id'siyle yeniden çözümleniyor.
• Conversation.contextId bilinçli olarak string (registry deseni döngüsel bağımlılığı önlemek için böyle tasarlanmış) — ama bu da Sipariş taraf ilişkileri'ndeki Invoice/Financial'daki gevşek referans sorununun bir başka örneği. Farkı: burada en azından tek bir tutarlı desen (registry + resolver) var; Invoice ve Financial'da öyle bir desen bile yok, her biri kendi başına gevşek.
• basket, purchase, post, price-analytics, buyer-group mesajlaşmayla hiç temas etmiyor. Sepette takılı kalan bir alıcıya proaktif mesaj, checkout sırasında soru sorma gibi bir akış bugün yok.

Çalışan (destek yetkilisi) tarafı

Buraya kadarki bölüm alıcının gördüğü tarafı anlatıyor. Konuşmayı gerçekten yürüten destek yetkilisi (officer/admin) tarafında da somut boşluklar var:

• Atama bir kuyruk değil, kura. getSupportOfficersForBuyer: alıcının AdminBuyerOfficer üzerinden atanmış bir yetkilisi varsa o kullanılıyor; yoksa Math.random() ile pazarlama yetkilileri arasından rastgele bir kişi seçiliyor. Yük dengeleme, müsaitlik/online durumu, uzmanlık bazlı yönlendirme yok.
• "Join" bir "claim" değil. POST conversation/:id/join herhangi bir officer/admin'in herhangi bir (private olmayan) konuşmaya katılmasına izin veriyor — sahiplenme/kilitleme yok. Birden fazla yetkili aynı konuşmaya girebilir, ya da hiçbiri girmeyebilir; zorlayıcı bir mekanizma yok.
• Kuyruk/iş yükü görünürlüğü yok. GET conversations, notParticipant: true ile "içinde olmadığım konuşmaları" listeleyebiliyor, ama bir durum alanı (ör. "atanmadı", "işleniyor", "çözüldü") yok — sıralama sadece updatedAt. Yetkili, neyin dikkat beklediğini listeye bakıp gözle ayırt etmek zorunda.
• Company/warehouse kapsaması yok. Officer/admin, platform genelindeki her private-olmayan konuşmayı görüp katılabiliyor. Uygulanmamış şirket ve depo planıyla veya v2'nin muhasebeye özgü depotOf kapsamıyla bağlantısı yok. Bugün B deposunda çalışan bir yetkili, A deposunun bir alıcısının SUPPORT konuşmasını da görüp katılabilir.
• SLA/performans ölçümü yok. İlk yanıt süresi, çözüm süresi, yetkili başına açık konuşma sayısı gibi hiçbir metrik tutulmuyor (AdminBuyerFeedbackHistory alıcı ilişkisinin genel sağlığını tutuyor, ama mesajlaşmaya özgü değil).

Sınıflandırma gerilimi

message modülünün kendisi (Conversation/Message CRUD, registry, AI auto-reply) gerçekten ortak/çekirdek altyapı — v1 modül alan haritası'ndaki sınıflandırma doğru. Ama PRODUCT ve (kurulacaksa) ORDER resolver'ları satış mantığı — bunlar zaten catalog ve order modüllerinde yaşıyor (resolver dosyaları oradan registry'ye kayıt oluyor), message'ın kendisinde değil. Yani bu zaten doğru yerde: Satış'a ait mesajlaşma mantığı, Satış modüllerinin içinde; sadece ortak taşıyıcı altyapı (message) paylaşılıyor. admin/report gibi başka bir "hem ortak hem domain'e özel" gerilimi değil — burada zaten çözülmüş bir desen var.

Öneri

• ORDER context'i için bir resolver eklenmeli (muhtemelen order modülünde, return-conversation.resolver.ts'e paralel) — ya da enum'dan tamamen kaldırılıp SUPPORT'a devredilmeli. İkisinden biri: ölü kod olarak kalmamalı.
• ProductRequest'e conversationId alanı eklenmeli — bugünkü dolaylı (buyer id'sinden yeniden çözme) yaklaşım yerine doğrudan referans.
• Konuşmaya bir atanan yetkili (assignedOfficerId) ve bir durum (ör. UNASSIGNED / IN_PROGRESS / RESOLVED) alanı eklenmeli — "join" kuralı bu ikisinin yerini tutmuyor.
• Konuşma görünürlüğü, mesajlaşmanın sahibi olduğu depo ve destek ekibi üzerinden sunucu tarafında daraltılmalı. Bu ihtiyaç, uygulanmamış Company/header planına bağlanmadan ayrıca tasarlanmalıdır.

Açık kalan iş

Yeni mobilin buyer mesajlaşma yüzeyi çalışır durumdadır. Panel destek kuyruğu, konuşma sahipliği, depo görünürlüğü ve SLA ölçümü ise v2'ye taşınmamış açık alanlardır. Paylaşılan belge değişiklikleri Sipariş taraf ilişkileri ve Geçiş ve veri sahipliği ile birlikte ele alınmalıdır.