İçeriğe geç

Bir göl, üç isim: Gerçeklerdeki ani bir değişikliğe dayanan sistemler kurmak

Kısa yanıt

Ontario Gölü artık ABD içinde Amerika Gölü olarak, Kanada'da eski adıyla ve diğer her yerde iki adıyla birlikte görünüyor. Hikâye siyasi görünüyor, ancak adı sabit bir gerçek olarak saklayan her sistem için bir mühendislik sınavı. Yer adlarındaki, vergi oranlarındaki ve düzenlemelerdeki değişiklikleri her seferinde kodu yeniden yazmadan karşılayan bir altyapı için pratik bir rehber.

Origami Ekibi

Editör ekibi · · 7 dk okuma

WhatsApp'ta paylaşın
Yayımladıklarımızı beğendiniz mi? Origami'yi Google'da tercih ettiğiniz kaynak olarak ekleyin.Add as a preferred source on Google
Bir göl, üç isim: Gerçeklerdeki ani bir değişikliğe dayanan sistemler kurmak

27 Ağustos 2026'da bir ABD başkanlık kararnamesi, federal coğrafi adlar veritabanında Ontario Gölü'nün adını Amerika Gölü olarak değiştirdi. Üç gün sonra Google Haritalar değişikliği uyguladı, Apple Haritalar da 2 Eylül'de onu izledi. Kanada bu adı reddetti ve iki ülke arasındaki sınır gölün tam içinden geçiyor.

Sonuç olarak tek bir coğrafi varlık artık nereden bakıldığına bağlı olarak üç etiket taşıyor: ABD'dekiler Amerika Gölü'nü, Kanada'dakiler Ontario Gölü'nü, diğer herkes ise ikisini birden görüyor. Bu ilk örnek değil; Meksika Körfezi de geçen yıl aynı mantıkla Amerika Körfezi olarak yeniden adlandırılmıştı.

Bunu siyasi bir haber olarak okuyup geçmek kolay. Aslında yaşanan şey bir mühendislik sınavı: Bu gölün adını sabit metin olarak saklayan dünyadaki her sistem, artık kullanıcılarının bir bölümüne yanlış bilgi gösteriyor. Bizim için önemli olan soru şu: Sisteminiz bu tür bir değişikliği karşılayacak şekilde mi kuruldu?

Temel hata: Kimlik yerine etiketi saklamak

Çoğu sistem gözün gördüğünü saklar. Şehir adlı bir metin alanında Riyad yazar, ülke alanında bir ülke adı bulunur, vergi oranı koda yazılmış bir sayıdır. Bu, olgunun kendisi değişene kadar verimli bir şekilde çalışır; sonra geçmiş verilerinizin artık yorumlanamadığını fark edersiniz.

Mühendislik kuralı basit: Sabit bir tanımlayıcı saklayın ve etiketi gösterim anında oluşturun. Göl, değişmeyen bir tanımlayıcıya ve dile, bağlama ve resmi kaynağa göre birden fazla ada sahip bir varlıktır. Tanımlayıcıyı saklarsanız ad değişikliği tek bir referans tablosunda yapılan bir güncellemeye dönüşür. Adı saklarsanız eksiksiz bir veri taşıma projesine dönüşür.

Bir Suudi şirketinin hayatında gerçekte neler değişiyor?

Göl uzak bir örnek. Liste ise öyle değil:

  • Vergi oranları. Suudi KDV'si 2020'de %5'ten %15'e çıktı ve sayıyı koduna yazmış şirketler zor bir hafta geçirdi. Değişikliğin kendisinden daha kötüsü: Eski faturalar eski oranlarını korumak zorunda.
  • E-fatura gereklilikleri. Zekât, Vergi ve Gümrük Kurumu (ZATCA) ile entegrasyon dalgaları aşama aşama geliyor ve her dalga teknik şartnamede bir değişiklik getirebiliyor.
  • Ülke adları. Türkiye 2022'de BM'deki resmi ad oldu, Makedonya Kuzey Makedonya, Svaziland ise Esvatini oldu. Sisteminize elle yazılmış her ülke listesi şimdiden güncelliğini yitirmiş durumda.
  • Ulusal adres ve veri formatları. Posta kodu, ulusal kimlik numarası, IBAN ve kuruluş numarası formatları güncelleniyor ve katı bir düzenli ifade olarak yazılmış her doğrulama ilk genişletmede bozuluyor.
  • Diğer pazarlardaki vergiler. Suudi Arabistan dışında satış yapıyorsanız değişiklik, haberlerini takip etmediğiniz ülkelerden gelir; tıpkı bu ay uygulama mağazalarının aynı anda üç ülkede yeni vergiler eklemesinde olduğu gibi.

Değişikliği karşılayan bir altyapı için beş ilke

  • Etiketler değil, tanımlayıcılar. Her varlığı sabit bir tanımlayıcıya bağlayın ve adları, dile ve kaynağa göre varlık başına birden fazla adı kabul eden ayrı bir tabloda tutun.
  • Değişebilen her değerde geçerlilik tarihi. Vergi oranı tek bir sayı değil, her birinin başlangıç ve bitiş tarihi olan bir değerler dizisidir. Yalnızca bu bile eski bir faturanın doğru oranla yeniden basılmasını çözer ve ilk denetimde bir muhasebe felaketini önler.
  • Kod olarak değil, yapılandırma olarak referans verileri. Ülke, para birimi, vergi ve bölge listeleri, yetkili bir yöneticinin güncellediği bir tabloda veya yapılandırma dosyasında yaşar; yeni bir sürüm ve bir geliştirme ekibi gerektiren kod içindeki sabitlerde değil.
  • Depolamadan ayrı bir gösterim katmanı. Saklanan bir şeydir; gösterilen başka bir şey. Bir sistem bunları ayırdığında, farklı kullanıcılara farklı adlar göstermek yeniden inşa değil bir ayar meselesi olur; Google'ın gölle yaptığı da tam olarak budur.
  • Tek bir doğruluk kaynağı. Vergi oranı veritabanında, fatura şablonunda ve satış raporunda yazılıysa, kaçınılmaz olarak birbirini tutmayacak üç kopyanız var demektir. Tek bir yer seçin ve geri kalanının oradan okumasını sağlayın.

Bu hafta sisteminizde pratik bir kontrol

Bunun için bir proje gerekmiyor. Geliştiricinizle oturun ve beş soru sorun:

  • Vergi oranı yarın değişse kaç dosyayı düzenleriz? Eski faturalar doğru kalır mı?
  • Ülke ve para birimi listemiz nerede: bir tabloda mı, yoksa koda mı yazılmış?
  • Şehir adlarını metin olarak mı, yoksa bir referansa bağlı tanımlayıcılar olarak mı saklıyoruz?
  • Kurum ulusal kimlik numarasına bir hane eklerse ya da posta kodu formatını değiştirirse ne olur?
  • Sistemde vergi değerini kaç yer biliyor? Birden fazlaysa, bir sonraki sorununuz bu.

Yanıtlar kırılgan noktalarınızı yarım saatte ortaya çıkarır ve bunların çoğu, ihtiyaç duyulduktan sonra değil önce ele alındığında günler içinde düzeltilir.

Origami'nin bakışı

Burada müşterilerimize tekrarladığımız bir ders görüyoruz: İyi bir sistem bugün çalışan değil, yeniden yazılmadan değişen bir dünyayı karşılayabilen sistemdir. İkisi arasındaki fark programcının zekâsı değil, ilk haftada alınan basit tasarım kararlarıdır: metin yerine bir tanımlayıcı, sabit bir sayı yerine bir geçerlilik tarihi, koddaki bir liste yerine bir referans tablosu.

Bu kararlar başlangıçta saatlere mal olur, sonrasında haftalar kazandırır. Bir tablodaki tek bir satırı güncelleyerek karşılanabilecek bir mevzuat değişikliği yüzünden günlerce fatura kesemeyen şirketler gördük ve neden her zaman aynı: hiçbir zaman değişmesi için tasarlanmamış bir yere yazılmış bir değer.

Sonuç

Bir göl bir ülkede yeniden adlandırıldı ve bu ad bir başka ülkede reddedildi; bu yüzden artık aynı anda üç etiket taşıyor. Bu bir istisna değil; referans verilerinin sürekli başına gelenlerin küçük bir örneği. Vergiler, adlar, formatlar ve düzenlemeler sizin kontrol etmediğiniz dış kararlarla değişir. Sizin kontrol ettiğiniz şey sisteminizin hazırlığıdır ve bu, değişiklik anında değil tasarımda belirlenir.

Kaynaklar

  • Resmi Google blogu: ad değişikliğinin Google Haritalar'da uygulanmasına ve bunun ABD, Kanada ve dünyanın geri kalanındaki kullanıcılara nasıl gösterildiğine ilişkin açıklama, 30 Ağustos 2026.
  • Reuters, TIME ve BBC'nin 27 Ağustos 2026 tarihli başkanlık kararnamesi, 2 Eylül'deki Apple Haritalar değişikliği ve Kanada'nın tutumu hakkındaki haberleri.
  • Zekât, Vergi ve Gümrük Kurumu (ZATCA), zatca.gov.sa: KDV oranları ve e-fatura aşamaları için resmi referans.
  • Birleşmiş Milletler: ülke adı değişikliklerinin belgelenmiş bir örneği olarak Türkiye'nin 2022'de resmi ad olarak kabul edilmesi.
  • #Sistem Tasarımı
  • #Referans Verileri
  • #E-Fatura
  • #Değişiklik Yönetimi
  • #Altyapı

Sık sorulan sorular

Ontario Gölü'nün adına ne oldu?

27 Ağustos 2026 tarihli bir ABD başkanlık kararnamesi, federal coğrafi adlar veritabanında adı Amerika Gölü olarak değiştirdi. Google Haritalar değişikliği üç gün sonra, Apple Haritalar ise 2 Eylül'de uyguladı; Kanada ise bu adı reddetti.

Ad neden ülkeye göre farklılık gösteriyor?

Çünkü Google adları her ülkenin resmi kaynaklarına göre gösteriyor. ABD'dekiler Amerika Gölü'nü, Kanada'dakiler Ontario Gölü'nü, diğer herkes ise iki adı birlikte görüyor.

Bunun şirket sistemleriyle ne ilgisi var?

Adı sabit metin olarak saklayan her sistem artık kullanıcılarının bir kısmına yanlış bilgi gösteriyor. Daha geniş ders şu: referans verileri — vergiler, ülke adları, veri formatları — dışarıdan alınan kararlarla değişir ve sisteminiz bunu yeniden yazılmadan karşılayabilmelidir.

En önemli ilke nedir?

Adın kendisini saklamak yerine varlık için sabit bir tanımlayıcı saklayın ve etiketi gösterim anında oluşturun. Böylece bir ad değişikliği, veri taşıma projesi olmak yerine tek bir referans tablosunda yapılan bir güncellemeye dönüşür.

Vergi oranındaki bir değişikliği nasıl ele almalıyım?

Oranı tek bir sayı olarak değil, her birinin başlangıç ve bitiş tarihi olan bir değerler dizisi olarak ele alın. Bu sayede eski faturalar yeniden basıldığında veya denetlendiğinde doğru oranlarını korur.

Sistemimin kırılgan olup olmadığını nasıl anlarım?

Geliştiricinize sorun: Vergi oranı yarın değişirse kaç dosya değişir? Ülke ve para birimi listesi nerede? Vergi değerini kaç yer biliyor? Birden fazla yer olması kırılganlığın ilk işaretidir.

Aklınızda bir proje mi var?

İşletmeniz için özel sistemler, uygulamalar ve web siteleri kuruyoruz. Fikrinizi anlatın, size net bir yanıt verelim.

Hizmetlerimizi görün

Bülten

Yeni makaleler ve seriler e-posta kutunuzda.

Origami'yi Google'da takip edin

Origami'yi tercih ettiğiniz kaynak olarak ekleyin; makalelerimiz Google Arama'da ve öne çıkan haberlerde size önce görünsün.

Add as a preferred source on Google