Ekibin işletebildiği sınırı koruyun
Birleşik e-ticaret sistemi işlem modelini karşılıyor ve ekibe anlaşılır bir çalışma alanı sunuyorsa onu korumak mantıklıdır. Belirli bir yeteneğin bağımsız değişmesi gerekiyorsa ve entegrasyonların sahibi belliyse composable yaklaşım değerlendirilebilir. Her sağlayıcı kısıtından kaçmak, uygulanabilir bir mimari hedef değildir.
Burada monolit, büyük ölçüde bütünleşik uygulamayı; composable ise açık arayüzlerle bağlanan yetenekleri ifade ediyor. Bunlar kusursuz zıtlıklar değil. Modüler bir uygulama tek dağıtım olarak kalabilir; ayrı satın alınmış servisler de pratikte birbirine sıkıca bağımlı olabilir.
Clodron açısından önemli olan mimari çizimdeki kutu sayısı değil, kutuların arasındaki sorumluluktur.
Bağımsızlık isteyen yeteneği bulun
Özel arama deneyimi, farklı fiyatlandırma motoru veya ortak ürün bilgi sistemi ayrışmayı haklı çıkarabilir. Bu parçanın ayrı sorumlusu, yayın ritmi ve mevcut sistemin karşılayamadığı açık bir ihtiyacı varsa gerekçe güçlenir.
Ayrışma yalnızca mevcut platform eski moda göründüğü için isteniyorsa gerekçe zayıftır. AWS'nin mimari karşılaştırması, birlikte dağıtım ile bağımsız servislerin farkını açıklıyor. Ancak composable e-ticaret, her işlevi mikroservise dönüştürmeyi zorunlu kılmaz.
Ürün keşfini iyileştirmek için tüm ticaret motorunu değiştirmek; ödeme, iade ve operasyon tarafında ilk soruna fayda sağlamayan işler çıkarabilir. Önce kısıtı adlandırın.
Siparişi sistemler arasından geçirin
Temsili bir senaryo düşünün: ödeme başarılı, stok ayırma isteği zaman aşımına uğruyor. Siparişin oluştuğuna hangi sistem karar veriyor? Tekrar denemeyi kim yapıyor? Çift tahsilat nasıl önleniyor? Destek ekibi açık kalan işlemi nerede görüyor?
Birleşik platformda bu sorumlulukların bir bölümü aynı ürünün içinde kalabilir. Ayrı yetenekler seçildiğinde aralarındaki sözleşmeyi entegrasyon katmanı kurmak zorundadır. Güvenilir servisleri satın almak, toplam akışı kendiliğinden güvenilir yapmaz.
İade, parçalı gönderim ve müşteri değişiklikleri de aynı incelemeyi ister. E-ticaretin operasyon tarafı yazımız, başarılı checkout demosunun neden yeterli olmadığını anlatıyor. Buradaki senaryolar bir sağlayıcıya yönelik kusur iddiası değil, test gereksinimleridir.
Koordinasyonun maliyetini dahil edin
Composable teklif; ürün, fiyat, sipariş ve müşteri için asıl kayıt sistemini belirtmeli. Olay işleme, mutabakat, izleme, erişim ve destek sorumluluklarını açıklamalı. Tedarikçiler sorunu birbirine yönlendirdiğinde müşteri akışını yine birinin düzeltmesi gerekir.
Birleşik teklif de sorgulanmalı. Eklentiler nasıl korunuyor, veri nasıl çıkarılıyor, hangi kurallar dolambaçlı çözümler istiyor? Basitlik, işe zarar veren kısıtları saklamamalı.
E-ticaret mühendisliği hizmetimiz iki yaklaşımda da anlamlı olabilir. Amaç mimari etiketi değil, tutarlı çalışan sistemi seçmek ve işletmektir.
Bu hafta dar bir ayrışmayı sınayın
Engellenen yeteneği, iş sonucunu ve bağımsızlık isteyen sorumluyu yazın. Ürün seçmeden önce girdileri ve çıktıları belirleyin. Güncelliğini yitiren veri, tekrar gelen mesaj ve erişilemeyen bağımlılığı kabul senaryolarına ekleyin.
Somut kısıt kalmıyorsa birleşik sistemi iyileştirin. Kalıyorsa onu çözen en küçük ayrışmayı prototipleyin. Operasyon ekibiyle hata yolunu deneyin. Sorumluluk açıkça çalışmadan kapsamı büyütmeyin.