E-ticaret sistemleri geliştirirken en zorlandığımız konulardan biri, fiziksel depo operasyonlarının karmaşasını kod düzeyinde pürüzsüz bir state machine (durum makinesi) ile yönetmekti. Özellikle bir siparişte birden fazla ürün olduğunda, depo personeli bunları nasıl koordine edecek? Moontra UCMS'i kurarken bu problemi sadece bir "Sipariş Hazırlanıyor" statüsü ile geçiştiremeyeceğimizi fark ettik. Bunun yerine, siparişleri parçalara bölen bir "İş Paketi" (Work Package) mimarisi tasarladık. Siparişi üç asenkron faza böldük: Toplama (Picking), Ayrıştırma (Sorting) ve Paketleme (Packing). Peki mimaride bunu nasıl kurduk? Sistemde `SingleItem` ve `MultiItem` adında iki farklı iş paketi tipi oluşturduk. Eğer sipariş tek ürünlüyse, akış "Ayrıştırma" adımını tamamen atlıyor ve doğrudan paketlemeye geçiyor. Paket tipi ne olursa olsun, bir aşamayı kimin başlattığı `assigneeHistory` kaydına düşüyor; iş el değiştirse bile zincir açık kalıyor. Burada aldığımız kritik bir mimari karar var. Ayrıştırma (Sorting) adımı hata riskinin en yüksek olduğu yerdir. Bu yüzden kod düzeyinde sıkı bir kısıt koyduk: `sortingAssignee !== performedBy` ise sistem hata fırlatıyor ve işlemi durduruyor. Yani ayrıştırmayı başlatan kişi, o adımı tamamlamak zorundadır. Aynı sahiplik kilidi paketlemede de duruyor, ama farklı bir mekanizmayla. Paketlemeyi başlatan uç atamayı tek bir atomik `findOneAndUpdate` ile kuruyor: koşul "durum Packing ve atanan kişi boş". İki personel aynı anda aynı pakete uzanırsa yalnız biri kazanıyor, diğeri `alreadyInPacking` ile geri dönüyor. Kilidi kuran kişi geri geldiğinde ise hata almıyor, kaldığı yerden devam ediyor. Burada `findOne` ile kontrol edip ardından `save()` çağırmak işe yaramazdı; iki isteğin arasındaki boşlukta aynı paket iki kişiye birden açılırdı. Fiziksel operasyonların değişken doğasını koda dökerken statik statüler yerine bu tarz dinamik state akışları hayat kurtarıyor. Siz benzer operasyonel yükleri çözerken nasıl mimari tasarımlar tercih ediyorsunuz? #yazilim #mimari #eticaret #developer #moontra