Salesforce Fiziksel Modelini Tasarlayın

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 10.‘u. Her modül kendi başına okunabilir. Önceki: Veriyi Tutarlı Tutmak · Sonraki: bölüm çalışma rehberi, ardından sonraki bölüm, Kurumsal Veriyi Anlamak

Bu modülün yanıtladığı soru: Mantıksal modelimizi bir Salesforce mimarisine nasıl dönüştürürüz?

Bu bölüm baştan sona platformun bir şekli olduğu üzerine uzun bir argümandı: standart ve özel nesneler, verinin yaşayabileceği yerler, alan türleri, ilişkiler, sahiplik, lisanslar, tutarlılık kuralları, depolama ve ölçek. Her biri 2. bölümün mantıksal modelinin nasıl inşa edileceğini değiştirebilir. Şimdi hepsini Steve Trucking’den tek bir kesit üzerinde bir araya getirelim.

Tek bir kesit, şirketin tamamı değil. Mimarların yaptığını gördüğüm bir hata, tüm kurumu tek bir diyagramda çözmeye çalışmaktır. Üzerinde akıl yürütebileceğimiz bir şey istiyorum: bir Perakende Ortağı bir yük listesi gönderir, Steve Trucking üzerindekileri teslim eder ve her teslimat hakkında ihtiyacımız olanı tutarız. Sonra fiziksel kararları tek tek veririz. Tam tasarım 1. Kısım kontrol noktasıdır.

Zaten Bildiklerimizle Başlayın

Kavramsal işi 2. bölüm yaptı: Perakende Ortağı, Alıcı, Yük Listesi, Teslimat, Teslimat Kalemi, durak türü, Ekip, Kamyon, Dağıtım Merkezi, fotoğraflar. İlişkileri adlandırdık ve ne anlama geldiklerini sorduk. Bunları tekrarlamayacağım. Şimdiki soru bu kavramların Salesforce’ta nasıl yaşadığıdır. Senaryo özetindeki bir olgu hemen önem kazanıyor: Steve Trucking randevular, ekipler ve mobil uygulama için zaten Field Service kullanıyor.

Perakende Ortağı: Bir Hesap İcat Etmeyin

Perakende Ortağı, Steve Trucking’in adına çalıştığı bir şirkettir. Salesforce’un şirketler için tasarlanmış bir nesnesi zaten var: Hesap. Tam uyum. Dolayısıyla iş birimi “ortak” diyor diye Retail_Partner__c yok. Diğer kuruluşlardan ayırmak için Retail Partner kayıt türüyle bir Hesap’tır ve onunla birlikte sözleşmeler, vakalar, DC müdürleri için Kişiler ve bu Kişiler için portal erişimi gelir. Kolay karar. Hepsi böyle değil.

Ortağın Sipariş Numarası Bizim Kimliğimiz Değildir

Her Perakende Ortağı kendi referanslarını gönderir. Bir ortağın siparişi 8843119 gibi, bir diğerininki A-984732 gibi görünür. Bu numaralar önemlidir, ama kimin numaralarıdır? Ortağın. Salesforce’un kendi kayıt kimliği var, ortağın da bizimle konuşurken kullandığı referans. İkisi de var olabilir; bu, 2. bölümün “tek şey, birkaç tanımlayıcı” fikridir.

Dolayısıyla ortağın referansı, entegrasyonun güncellemeleri eşleştirmek için kullandığı bir Harici Kimlik olur. Ve iki ortak aynı numarayı kullanabileceği için kimlik yalnızca referans değil, ortak artı referanstır. İlk o geldi diye bir ortağın numarasını teslimatın evrensel kimliği yapmayın ve bir entegrasyonu bir kaydı bulması gerektiği her seferinde bir metin alanında arama yapmaya zorlamayın.

Teslimat: Ana Gemiye Bakın

Delivery__c oluşturmanın cazip geldiği yer burası. İş birimi “teslimat” dedi, o halde bir Teslimat nesnesine ihtiyacımız var. Önce yapmanızı istemediğim şey tam olarak bu. 2. modülde yaptığımız gibi ana gemiye bakın. Salesforce’un bir konumda gerçekleştirilen, yaşam döngüsü, kalemleri, planlaması ve sahada bir ekibi olan iş için zaten neyi var? Field Service’in İş Emri (Work Order): Salesforce onu bir müşteri için gerçekleştirilecek saha hizmeti işi olarak tanımlar (WorkOrder (opens in a new tab), İngilizce). Planlanan ziyaret ve zaman aralığı Servis Randevusu’dur (Service Appointment) ve sevk biriminin planladığı ve ekibin uygulamasının gösterdiği odur.

Dolayısıyla Teslimat → İş Emri. Sözcükler eşleştiği için değil; eşleşmiyorlar. Davranış, zaten parasını ödediğimiz ve kullanmayı amaçladığımız platform yeteneğiyle eşleştiği için. Bir standart nesnenin işin sözcük dağarcığını paylaşması gerekmez. Kavramı doğru temsil etmesi gerekir.

Click to enlarge

4 adımdan 1.‘si: ana gemi. Her kart iş kavramıdır, altında Salesforce nesnesiyle.

Ama Standart Nesneler Yükleriyle Gelir

Diğer yarısı: İş Emri bedava değildir. Field Service lisanslamasını, kendi ilişkilerini, güvenlik davranışını, zorunlu alanlarını, otomasyonunu ve yaşam döngüsünü getirir ve platformun diğer kısımları onun belirli bir şekilde davranmasını bekler. Onu, uyum tam olduğu ve etrafında inşa edileni kullandığımız için seçiyoruz. Steve Trucking Field Service’ten hiçbir şey istemeseydi ve model her adımda süreçle savaşsaydı yeniden düşünürdüm. Mimari etiket değil, uyumdur.

Teslimat Kalemleri: Modeli İzleyin

Teslimat bir İş Emri olduktan sonra herhangi bir şey icat etmeden önce o modelin geri kalanına bakın. Bir İş Emri Satır Öğesi (Work Order Line Item), bir iş emrindeki alt görevdir (WorkOrderLineItem (opens in a new tab), İngilizce): buzdolabı, kurulum, eski ürünün götürülmesi. Dolayısıyla Teslimat Kalemi → İş Emri Satır Öğesi. İlk kararın ikincisini şekillendirdiğine dikkat edin. Her varlık için tek başına bir nesne seçmiyoruz. Bir modeli benimseyin ve etrafında özel yapılar inşa etmeden önce geri kalanını anlayın.

Bu Ne Tür Bir Durak?

Steve Trucking’de bir durak yalnızca teslimat, kurulumlu teslimat ya da eski ürünü götürmeli teslimattır ve her türün kendi süresi, ekip becerileri ve kurulum kontrol listesi vardır. 2. bölümde bunun bir etiket değil, bir varlık olduğuna karar verdik. Field Service’te zaten bir tane var: iş emirlerine ve satır öğelerine uygulanabilen, bir iş türü için şablon olan İş Türü (Work Type) (WorkType (opens in a new tab), İngilizce). Dolayısıyla Durak Türü → İş Türü. Yine, İş Türü adında bir şey var diye değil, kavram ve davranış örtüştüğü için.

Click to enlarge

4 adımdan 2.‘si: modeli izleyin. Satır öğeleri ve İş Türü, İş Emri ile birlikte gelir.

Yük Listesi: İşte Şimdi Özel Bir Nesne İstiyorum

“Ortağın Phoenix DC’deki Salı günü listesi” için bir standart nesne var mı? Pek yok ve yalnızca standart kaldık diyebilmek için onu ilgisiz bir nesneye zorlamayacağım. Yük Listesi → Manifest__c. Teslim alma birimidir: nereden geldiği (bir dosya, bir API grubu), ne zaman geldiği, durumu ve toplamları ve bir ortak onu aynı gün yeniden gönderdiğinde neyin karşılaştırılacağı. Her yük listesi satırı ona geri bağlanan bir İş Emri olur.

Özel nesne başarısızlık değildir. Bir kavramın temiz bir standart karşılığı olmadığında platformun bize verdiği şeydir. Hata özel bir nesne oluşturmak değil; platformda o kavramın zaten olup olmadığını kontrol etmeden oluşturmaktır.

Click to enlarge

4 adımdan 3.‘sü: hiçbir standart nesnenin uymadığı yerdeki tek özel nesne.

Fotoğraflar: Salesforce Saklayabiliyor Diye Saklaması Gerekmez

“Teslimat fotoğraflarına Salesforce’ta ihtiyacımız var.” “Salesforce’ta” ne demek? Kullanıcıların onları Salesforce’tan görmesi gerekiyor, evet. Bu, görüntü dosyalarının çekirdek depolamada yaşaması gerektiği anlamına mı gelir? Mutlaka değil. Sıfırları sayın: teslimat başına yaklaşık dört fotoğraf, kurulumlarda daha fazla, yılda bir milyon teslimatta yılda dört beş milyon fotoğraf eder ve teslimatlar yılda %30 büyüyor.

Bu yüzden başlangıç pozisyonum: kullanıcıların fotoğraflara erişmesi gerekiyor diye çekirdek org’u dev bir fotoğraf deposuna dönüştürmeyin. Dosyalar, çekirdeğin dışında, bu hacim için inşa edilmiş depolamaya aittir; Salesforce ise onları bulmak ve göstermek için ihtiyaç duyduğunu tutar: bir referans, bir sayı ya da fotoğraf başına küçük bir dizin kaydı ve gerekli kurulum fotoğraflarının tamamlandığını gösteren bir işaret. Veriye erişim ile verinin fiziksel olarak nerede yaşadığı iki farklı sorudur. Bu, 4. modülün geri dönüşüdür.

Alanlar: Anlamı Görünür Kılın

İş Emri’nin alanlara ihtiyacı var: ortağın referansı, teslimat zaman aralığı, gerçek teslimat saati, durum, “kapı şifresi” ya da “bahçede köpek var” gibi notlar. Bunu bir alan kataloğuna dönüştürmeyeceğim; bunu 6. modül yaptı. Soruları her birine uygulayın: ne anlama geldiği, sahibinin kim olduğu, değişip değişmediği, bir tanımlayıcı mı, kontrollü bir sözcük dağarcığı mı olduğu, saklanan mı türetilen mi olduğu, hassas olup olmadığı. Ortağın referansı Harici Kimliktir; dolayısıyla benzersizliği yalnızca bir onay kutusu değil, entegrasyon sözleşmesinin bir parçasıdır. Gerçek teslimat saati bir andır, yani Tarih/Saat. Durum davranışı yönlendirir, yani kontrollü bir liste, asla serbest metin değil. Ve bir kişinin evi hakkındaki teslimat notları kişisel veridir, yani sınıflandırılır. Her alan anlamına kadar geriye izlenir.

İlişkiler: Kutuları Yalnızca Bağlamayın

Hesap’tan İş Emri’ne, İş Emri’nden satır öğelerine, Yük Listesi’nden İş Emri’ne, durağı tanımlayan İş Türü. Sonra her çizgi için 7. modülün soruları: alt kayıt tek başına var olabilir mi, sahibi kim, erişim devralınıyor mu, taşınabilir mi, silmede ne olur, kaç alt kayıt birikebilir? Bir avuç Perakende Ortağı hesabının altındaki her İş Emri, üst kayıt başına yüz binlerce alt kayıt demektir: 2. Kısım’da yanıtlayacağımız bir çarpıklık sorusu. Ve standart Field Service ilişkileri için bizim tasarlayacağımız şeyle eşleştiklerini varsaymak yerine Salesforce’un onları zaten nasıl kurduğunu kontrol edin. Standart bir modeli benimsediğinizde Salesforce’un onun içinde verdiği kararları da benimsersiniz. Üzerine inşa etmeden önce onları anlayın.

Sahiplik ve Alıcı: Varsayılanın Karar Vermesine İzin Vermeyin

Bir varsayılanın bizim yerimize seve seve vereceği iki karar.

Bir teslimatın sahibi kim? Bunu 8. modülde yanıtladık ve doğrudan İş Emri’ne taşınır: burada sahiplik kimsenin erişimini belirlemiyor; bu yüzden oluşturduğu İş Emirlerinin sahibi entegrasyon kullanıcısıdır. Sevk görevlileri kendi dağıtım merkezlerininkini, ekipler kendi rotalarınınkini ve her Perakende Ortağı kendininkini portal üzerinden görür; hepsi sahiplikle değil, paylaşımla. Entegrasyon kullanıcısının rolü yoktur ve paylaşım kurallarımızın kullandığı genel grupların dışında kalır, çünkü günde 3.300 kayıtla üç günde 10.000 kaydı geçer. Ve o kullanıcı bir gün değiştirilirse ne olacağını yazıya dökeriz.

Alıcı nedir? Bir Kişi mi? Bir kişi hesabı mı? Yalnızca teslimatta tutulan bir şey mi? Bu, Steve Trucking’in bu insanlarla herhangi bir ilişkisi olup olmadığına (onlar Perakende Ortaklarının müşterileri), bir ortağın başka bir ortağınkini hiç görüp göremeyeceğine, kişisel verilerinin ne kadar süre saklanabileceğine ve ölçeğe bağlıdır: yılda yaklaşık bir milyon yeni Alıcı. Henüz bunların hepsine sahip değiliz ve bu sorun değil. Bazen doğru yanıt henüz yeterince bilmiyoruz’dur. Soruyu yazıya dökün ve bilgiyi toplamaya gidin; belirsizliği bir özel nesnenin içine gömmeyin. Bunu, 4. ile 6. bölümler bize kurumsal ve ana veri resmini verdikten sonra, 1. Kısım kontrol noktasında yanıtlıyoruz.

Tutarlılık: Modeli Doğru Katmanda Koruyun

9. modülün merdiveni geçerlidir: ortağın referansı benzersiz bir Harici Kimliktir, böylece yeniden gönderilen bir yük listesi yinelenen kayıt oluşturmak yerine upsert yapar; durum kısıtlı bir listedir; gerçek teslimat saati yalnızca durum Teslim edildi olduğunda zorunludur; bir kurulum durağı kontrol listesi ve fotoğrafları olmadan kapanamaz. Tek bir dev akış değil. Her kural kendi basamağında.

Her Parça Nerede Yaşar

Kesitin üzerinden 4. modülün sorusuyla bir kez daha geçelim: her veri parçası nerede yaşıyor? Ders sunumumda bu tek bir slayttır, mantıksala karşı fiziksel: 2. bölümdeki mantıksal varlıklar ve her birinin fiziksel olarak nereye düştüğü: çekirdekte, bir sObject (özelse __c) ya da büyük nesne (__b) olarak; ya da çekirdek dışında, bir harici nesne (__x) ya da Salesforce’a hiç girmeyen veri olarak.

• Çekirdekte, her gün üzerinde çalışılan: Hesap, İş Emirleri ve satır öğeleri, Servis Randevuları, İş Türleri, Manifest__c.
• Çekirdekte, arşivlenmiş: üç yıldan eski teslimatlar, büyük bir nesne olan Teslimat Geçmişi’ne (Delivery History) taşınır; talepler için hâlâ orada, arka bahçedeki kulübede.
• Başvurulan: Perakende Ortağının kendi sipariş ayrıntıları ortağın sisteminde kalır; ortağın referansını bir Harici Kimlik olarak tutarız ve geri kalanına biri ihtiyaç duyduğunda bir harici nesne ya da entegrasyon üzerinden ulaşırız.
• Çekirdek dışında: fotoğraflar, milyonlarca görsel için inşa edilmiş depolamada, İş Emri’nden bir bağlantıyla.

Fiziksel model budur: yalnızca hangi nesne değil, hangi yuva.

Şimdi Kesitin Bütününe Bakın

• Perakende Ortağı → Retail Partner kayıt türüyle Hesap; Kişi olarak DC müdürleri.
• Teslimat → bir Servis Randevusu ile planlanan Field Service İş Emri.
• Teslimat Kalemi → İş Emri Satır Öğesi.
• Durak Türü → İş Türü.
• Yük Listesi → özel Manifest__c.
• Ortak referansı → İş Emri’nde ortak başına benzersiz Harici Kimlik.
• Fotoğraflar → çekirdeğin dışında saklanır; Salesforce referansı ve tamamlanma işaretini tutar.
• Teslimat geçmişi → üç yıldan sonra büyük bir nesneye arşivlenir.
• Sahiplik → entegrasyon kullanıcısı, erişim paylaşım üzerinden (8. modül).
• Alıcı → 1. Kısım kontrol noktası için açık.

Click to enlarge

4 adımdan 4.‘sü: kesitin bütünü; çekirdekte, arşivlenmiş ve çekirdek dışında. Her çizgi bir arama ilişkisidir: Salesforce, Field Service’i arama ilişkileri üzerine kurdu ve biz onu benimserken kararlarını da benimsiyoruz.

Diyagram Mimari Değildir

O diyagramı size verebilirim ve yeterli değildir. Mimari, arkasındaki gerekçedir. Neden Hesap? Tam uyumlu bir şirket. Neden Delivery__c değil de İş Emri? Teslimat saha işi gibi davranıyor ve Field Service zaten yerinde. Neden özel bir Yük Listesi? Temiz bir standart karşılığı yok. Fotoğraflar neden yalnızca Dosyalar değil? Hacim ve depolama ekonomisi. Neden bir Harici Kimlik? Başka bir sistemin sınırın ötesinde sabit bir kimliğe ihtiyacı var. İş Emirlerinin sahibi neden entegrasyon kullanıcısı? Burada sahiplik erişimi belirlemiyor ve bu, denetim izini dürüst tutuyor. Alıcı neden hâlâ açık? Henüz yeterince soruyu yanıtlamadık. Çizgiler çıktıdır; onları kararlar üretti.

İşte 3. bölümden edinip ayrılmanızı istediğim alışkanlık. Fiziksel bir modeldeki herhangi bir şeyi gösterin ve neden? diye sorun. Neden bu nesne, bu tür, bu ilişki, bu sahip, bu yer, bu kural? Yanıtı geriye doğru izleyebilmelisiniz: yapılandırmadan fiziksel modele, mantıksal modele, iş gereksinimine. İzleyemiyorsanız biri Kurulum’dan yola çıkarak tasarlamıştır.

Ve tam olarak hesaplamadığımız sayıları fark etmişsinizdir: ortak başına teslimatlar, satır öğeleri, fotoğraflar, saklama, arşivleme. Güzel. Bir tasarımı kesinleştirmeden önce sıfır sayısını sorun: elli bin kayıtta harika çalışan bir model beş yüz milyon kayıtta çok farklı davranabilir. Bu, 2. Kısım.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Bir yapay zekâya Steve Trucking senaryo özetini verin, saniyeler içinde bir şema üretir: Hesap, İş Emri, özel nesneler, alanlar, hatta dağıtım meta verisi. Bu harika bir hızlandırıcıdır ve inceleme değildir. Mimarın işi, eşlemeleri ve sonuçlarını kontrol etmeye kayar: uyum, lisanslar, sahiplik, yaşam döngüsü, ölçek, kimlik, güvenlik ve platform dışında kalanlar. Yapay zekâ roket iticisidir; doğru yöne bakıp bakmadığınızı size söylemez.

Mimarın Burada Karar Verdikleri

• Her iş kavramının Salesforce’a nasıl eşlendiği: bir standart nesne, bir özel nesne ya da çekirdeğin dışında bir şey.
• Hangi tanımlayıcıların, alanların ve ilişkilerin iş anlamını sessizce değiştirmeden uyguladığı.
• Benimsediğiniz standart bir modelle birlikte hangi platform davranışının ve lisanslamanın geldiği.
• Tasarım tamamlanmadan önce hangi sahiplik, yaşam döngüsü, tutarlılık, depolama ve ölçek kararlarının verilmesi gerektiği.
• Hangi soruların keyfî bir uygulama seçiminin arkasına gizlenmek yerine açıkça açık bırakıldığı.

Bu bölümün başında modelin Salesforce’ta nasıl yaşaması gerektiğini sorduk. Salesforce veri mimarisi budur: nesne oluşturmak değil, Kurulum’u ezberlemek değil, daha güzel kutular çizmek değil; iş modelini bilinçli olarak platformun şekline uydurmak. Her yapı bir taahhüttür. Açıklayabildiklerinizi verin.

Daha Fazlası

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) ve WorkType (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Steve Trucking senaryo özeti (İngilizce).