41 seçenekli bir konfigüratör neler gerektirir
Bir konfigüratörde asıl iş kurallardadır: hangi seçeneklerin birbirini dışladığı ve hangi kombinasyonların fiyatı değiştirdiği. Prefabrik garaj üreten bir firma için 41 seçenekli bir konfigüratör kurduk. Bu büyüklükte bağımlılıkların veri olarak tutulması gerekir; koda gömülü if blokları yeni bir seçenek eklendiği anda bozulur.
Bağımlılıkları veride tutmak
Birkaç düzine seçenekte olası kombinasyonlar tek tek listelenemeyecek kadar çoktur; bu yüzden listelenmez, doğrulanır. Her seçenek, bağımlılıkları ve dışlamalarıyla birlikte veri olarak saklanır ve her değişiklikte mevcut seçime göre denetlenir.
En önemli sorun eski kalan bir seçimdir. Bir seçenek ikinci bir alanı açar, orada bir seçim yapılır, sonra ilk seçenek değişir ve o seçim artık geçersizdir. Doğrulama yalnız ileri doğru çalışırsa eski seçim siparişte kalır ve fiyatlanır. Bu yüzden her değişiklikten sonra bütün konfigürasyon yeniden denetlenir; geçersiz kalan her şey toplamdan görünür biçimde düşer ki müşteri toplamın neden değiştiğini görsün.
Doğrulama iki yerde çalışır: tarayıcıda, form anında yanıt versin diye; sunucuda, çünkü ziyaretçi tarayıcıda çalışan kodu değiştirebilir. Bu, iki kez denetlenen tek bir kural kümesidir ve iki denetim zamanla ayrışabilir. Her tıklamada sunucuya gidip gelmek bunu önler ama zayıf bağlantıda formu yavaşlatır. Kurallar değiştikçe iki denetimi uyumlu tutmak işin zor tarafıdır; uyuşmazlarsa müşteri gönder düğmesine bastığında toplam birden değişir.
Kombinasyona göre fiyatlandırma
Seçeneklerin çoğu fiyata sabit bir tutar ekler. Bazı fiyatlar ise birkaç seçeneğin birlikteliğine bağlıdır; bu yüzden fiyat kuralının kendi modeli vardır: bütün konfigürasyon üzerinde bir koşul ve bu koşulun fiyata etkisi.
Hesap kesin ve tekrarlanabilir olmalı. Para kuruş cinsinden tam sayılarla hesaplanır; sonuç net ve brüt tutarlarla birlikte KDV oranını da içerecek şekilde saklanır. Aynı konfigürasyon iki kez gönderildiğinde, bir kural değiştikten sonra bile aynı fiyatı üretmelidir. Bu yüzden fiyat kuralları sürümlenir ve her teklif hangi sürümle fiyatlandığını kaydeder. Aksi hâlde sıradan bir fiyat güncellemesi daha önce gönderilmiş bütün tekliflerin geçmişini değiştirirdi.
Kuralları düzenleyecek kişi onları okuyabilmeli. Her kuralı yazmaya izin veren bir editör, birbiriyle çelişen kuralları da yazdırır; bu yüzden editörü motorun desteklediği kural türleriyle sınırlıyoruz. Yeni bir kural türü kod değişikliği gerektirir.
Teklif belgesi
Kolayca küçümsenen ikinci gereksinim belge üretimidir. Alıcılar teklifi kendi müşterilerine iletir ya da bir ihaleye ekler; bu yüzden teklif, referans numarası, seçilen konfigürasyon, fiyat ve şartları içeren markalı bir PDF’tir. Bu PDF sunucuda üretilir.
Tarayıcıdan yazdırmak, çıktıyı yazdıran makineye bağımlı kılar: yazı tipleri, sayfa boyutu, işletim sisteminin yerine ne koyduğu. İletilen bir belgenin her kopyada birebir aynı olması gerekir; bu yüzden yazı tiplerinin sabit olduğu yerde, sunucu tarafında işlenmelidir. İki dilli bir site buna bir kısıt daha ekler: yerleşimin her iki dilde de bozulmaması gerekir.
Referans numaraları da özen ister. Çift tıklama ya da zaman aşımından sonraki bir yeniden deneme aynı konfigürasyon için iki referans numarası üretmemelidir; bu yüzden tekrarlanan istek mevcut teklifi döndürür. Saklanan bir teklif şunları taşır:
seçilen konfigürasyonun tamamı
hangi fiyat kuralı sürümüne göre fiyatlandığı
para birimi ve KDV oranı, saklanmış değerler olarak
zaman damgasıyla birlikte referans numarası ve üretilen belge
Teklifi kaydederken seçilen konfigürasyonu ve üretilen PDF’i birlikte saklıyoruz. Müşteri bir yıl sonra fiyata itiraz ederse konfigürasyon fiyatın nasıl hesaplandığını, PDF de neyin gönderildiğini gösterir.
Getiri ve maliyet
Sistem çalışmaya başlayınca personel her talebi elle fiyatlamaz ve teklifler arada bir fiyatlama turu olmadan gider. Üretici fiyatları değiştirebilir ve motorun zaten desteklediği türde seçenekler ekleyebilir; yeni kural türlerini biz ekleriz.
Bedeli şu: bu bir uygulamadır. Seçenekleri ve aralarındaki kuralları tutan ilişkisel bir model ve sunucuda çalışan hesaplamalar gerektirir. Hazır web sitesi araçları sayfa üretir ve bu modele yer bırakmaz; bu yüzden kendi yığınımızda çalışır: Next.js, Spring Boot, PostgreSQL, Flyway migration’ları ve Docker imajları. Bakımı, barındırılan hazır bir siteden fazladır.
Bu, kapsamın iş başlamadan yazılması demektir. Kabul ölçütleri seçenek sayısı, motorun desteklediği kural türleri, PDF’in içeriği ve sonradan neyin düzenlenebilir kalacağıdır. Yazılı kapsam ve anlaşılan revizyon turlarıyla sabit fiyata çalışıyoruz; bu ancak bu çizgi baştan çizilirse işler.
Bunları ilk teklifler gönderildikten sonra eklemek, fiyat mantığını ve saklanan belgeleri yeniden açmak demektir.
Bu tür işleri nasıl kapsamlayıp fiyatladığımız hizmetler sayfasında.
