Mevcut kanıtlar Kanonik Veri Modelleri üzerinden Bağlamsallığın benimsenmesini destekliyor mu?

"Kanonik" fikir yazılımda yaygındır; Kanonik Model , Kanonik Şema , Kanonik Veri Modeli ve benzeri gibi desenler , gelişimde tekrar tekrar ortaya çıkıyor gibi görünüyor.

Birçok geliştirici gibi, kanonik bir modele ihtiyacınız olan geleneksel bilgeliği, eleştirel olmayan bir şekilde takip ettim , aksi takdirde haritacıların ve çevirmenlerin birleşik patlamasıyla karşılaşacaksınız . Ya da en azından, ben alışık ben ilk biraz-rezil okurken birkaç yıl öncesine kadar bunu hiçbir Güven EF Oy :

Bir zamanlar kanonik veri modellerinin peşinde koşmayı destekleyen hipotezler, fikir uygulamaya konduktan sonra keşfedilecek faktörleri içermiyordu ve içeremedi. Yıllarca süren deneme yanılma yoluyla, kanonik bir veri modelinin kullanılabileceği her bir bağlam için ayrı modeller kullanmanın en az karmaşık yaklaşım olduğunu, en az maliyetli yaklaşım olduğunu ve daha fazla sürdürülebilirlik ve genişletilebilirliğe yol açan yaklaşım olduğunu gördük. bağlamsal modeller kullanan uygulamalar ve uç noktalardan oluşur ve bu, kanonik modellerin yaptığı yazılım entropisini teşvik etmeyen bir yaklaşımdır.

Deneme, iddialarını destekleyecek hiçbir kanıt sunmuyor, ancak CDM yaklaşımını alternatifi deneyecek kadar uzun süre sorgulamama neden oldu ve ortaya çıkan yazılım tam anlamıyla veya mecazi olarak patlamadı. Ancak bu tecritte bir sürü demek değildir; Şanslı olabilirdim.

Merak ediyorum, bir yazılım sisteminde veya mimaride kanonik bir modele ve bağlamsal modele sahip olmanın pratik, uzun vadeli etkileri konusunda ciddi bir araştırma yapıldı mı?

Ya da bunu sormak için çok erkense, bir CDM'den bağımsız bağlamsal modellere geçiş yapan kişisel deneyimler hakkında geliştiriciler / mimarlar yazdı mı, yoksa tam tersi ve üretkenlik, karmaşıklık veya güvenilirlik gibi şeyler üzerindeki pratik etkiler nelerdi?

Farklı düzeylerdeki farklılıklar, yani tek bir uygulamada aynı modeli kullanma veya bir uygulama sistemi veya tüm işletme genelinde kullanma konusunda ne olacak?

(Sadece gerçekler, lütfen; savaş hikayeleri açıktır, ancak spekülasyon yoktur.)

EF Güvensizlik Oyu makalesine yanıt olarak Tim Mallalieu şöyle yazar:

İnsanların “kanonik şemalar” için XSD kullanımını evangelize ettiğimiz günlere dönmelerini tavsiye etmiyoruz. İnsanların bunun izlenebilir olduğunu düşündüklerine inanmıyorum. Bununla birlikte, inandığımız şey, birçok etki alanı modelini tanımlayabileceğiniz tek bir meta-modelin (isterseniz EDM) arzu edilmesidir ve tek bir dilbilgisine sahip olarak, herhangi bir verilen etki alanı modeli.

Örneğin, 600 tablo içeren bir veritabanına yazılması gereken bir uygulamayı düşünün. Bu uygulamanın içinde 600 Varlık Türü bulunan tek bir model olması gerektiğine inanıyor muyum? Hayır… Ayrıca, belirli bir alan adı varlığının (Müşteri diyelim) bu uygulamada yalnızca bir şekli olduğuna ve bu şeklin tüm Kuruluş için standart şekil olması gerektiğine inanıyor muyum?… Heck no.

Kanonik Model için Wikipedia makalesi, Kurumsal Hizmet Veri Yolu , Hizmet Odaklı Mimari ve CORBA gibi şeylerden bahsediyor. Hepsi, işletmenin veri çoğalması ve iletişim zorluklarına, Hepsine hükmedecek Tek Yüzük'e çözüm olarak sunuldu . ^TM Başardılar mı? Yoksa kendi ağırlıkları altında mı çöktüler?

Kişisel deneyimler istedin, bu yüzden sana bir tane vereceğim. Havacılık ve uzay endüstrisinde telemetriyi çok kullanıyoruz. Telemetri sistemleri ile ilgili zorluklardan biri, farklı test aralıklarının test verilerini birbirleriyle anlamlı bir şekilde iletmeleri için bir yol bulmaktır. Ortak terimlerin bir veri sözlüğünü tanımlamaya çalışana kadar bu sorun yeterince basit görünüyor.

"Yükseklik" ne anlama geliyor? Yerden yükseklik mi yoksa deniz seviyesinden yükseklik mi? Ya bir denizaltıdan bahsediyorsan? Sonra derinliği, irtifa değil. Orduya göre, "iletim" kelimesi, bir radar yemeğine atıfta bulunduğunuzda, yer tabanlı bir araçtan daha farklı bir anlama sahiptir. Bir uçağın yuvarlanmasına neden olan kanat yüzeyine bazı düzlemlerde "kanatçık" ve diğerlerinde "yükselme" denir.

Bu sadece takip eden sorunların dağına bir ipucu. Veri iletişimi için standartlar olmasına rağmen, her test aralığı farklıdır ve farklı ihtiyaçları, hedefleri ve öncelikleri vardır. Standartlar, aynı aralıktaki farklı projeler arasında bile farklılık gösterebilir. Bu nedenle, test aralıkları, çözümün her şeyi tek bir yekpare sistemle değiştirerek değil , basit iletişim protokolleri üzerinde anlaşarak ve bir aralığın kelime dağarcığından diğerine çevirmenin yollarını sağlayarak geleceğini anlar .

Büyük şirketlerin karşılaştığı sorunlar benzerdir. Microsoft, monolitik olarak düşünmeye eğilimlidir, ancak bunun nedeni, şirketlerinin büyük ölçüde monolitik olmasıdır. Çok farklı kültürlere ve iş yapma yollarına (hatta aynı şirketteki farklı departmanlar arasında) farklı şirketler arasında iletişim kurmanız gerektiğinde, Onları Yönetmek İçin Tek Yüzük. ^TM hemen parçalanmaya başlar.