Apakah bukti saat ini mendukung adopsi Kontekstual atas Model Data Canonical?

Gagasan "kanonik" meresap dalam perangkat lunak; pola-pola seperti Canonical Model , Canonical Schema , Canonical Data Model dan sebagainya, tampaknya muncul lagi dan lagi dalam pengembangan.

Seperti banyak pengembang, saya sering mengikuti, tanpa kritik, kearifan konvensional bahwa Anda memerlukan model kanonik, jika tidak, Anda akan menghadapi ledakan kombinasi pembuat peta dan penerjemah. Atau setidaknya, saya biasa melakukannya sampai beberapa tahun yang lalu ketika saya pertama kali membaca EF Vote of No Confidence :

Hipotesis yang pernah mendukung pengejaran model data kanonik tidak dan tidak dapat memasukkan faktor-faktor yang akan ditemukan setelah ide tersebut dipraktikkan. Kami telah menemukan, selama bertahun-tahun coba-coba, bahwa menggunakan model terpisah untuk setiap konteks individu di mana model data kanonik dapat digunakan adalah pendekatan yang paling kompleks, merupakan pendekatan yang paling murah, dan yang mengarah pada kemampuan pemeliharaan dan ekstensibilitas yang lebih besar. aplikasi dan titik akhir menggunakan model kontekstual, dan ini merupakan pendekatan yang tidak mendorong entropi perangkat lunak yang dilakukan oleh model kanonik.

Esai tidak menyajikan bukti apa pun untuk mendukung klaimnya, tetapi membuat saya mempertanyakan pendekatan CDM cukup lama untuk mencoba alternatifnya, dan perangkat lunak yang dihasilkan tidak meledak, secara harfiah atau kiasan. Tapi itu tidak berarti banyak terisolasi; Aku bisa saja beruntung.

Jadi saya bertanya-tanya, apakah ada penelitian serius yang dilakukan mengenai efek praktis jangka panjang dari memiliki model kanonik vs model kontekstual dalam sistem perangkat lunak atau arsitektur?

Atau, jika terlalu dini untuk menanyakan hal itu, apakah ada pengembang / arsitek menulis tentang pengalaman pribadi beralih dari CDM ke model kontekstual independen, atau sebaliknya, dan apa efek praktis pada hal-hal seperti produktivitas, kompleksitas, atau keandalan?

Bagaimana dengan perbedaan pada tingkat yang berbeda, yaitu menggunakan model yang sama di satu aplikasi vs. menggunakannya di seluruh sistem aplikasi atau seluruh perusahaan?

(Tolong hanya fakta; cerita perang disambut tetapi tidak ada spekulasi.)

— Aaronaught
sumber

Saya tidak tahu apa yang mereka bicarakan dalam artikel "Vote of No Confidence". Sisa artikel ini masuk akal, tetapi bagian tentang Canonicalism sangat abstrak sehingga tidak berarti apa-apa. Akan lebih baik jika mereka memberikan contoh tentang apa yang mereka bicarakan.

— Robert Harvey

@Robert: Saya tidak tahu apakah ada kebenarannya, tetapi cukup jelas bagi saya apa artinya ... pasti Anda terbiasa dengan pola CM / CDM? Dalam penjelmaannya yang paling sederhana, ia berbagi satu EF tunggal (atau Linq to SQL, atau apa pun) monolitik model di seluruh aplikasi, bukan lebih (dirasakan) pendekatan saluran-rekaman menulis pertanyaan khusus untuk bagian-bagian tertentu dari aplikasi. Pada level yang lebih tinggi, ini mengadopsi skema universal untuk seluruh organisasi yang harus diterjemahkan oleh semua aplikasi / sistem individual.

— Aaronaught

Kedengarannya seperti debat EF berpusat pada desain meja pertama vs kelas pertama, karena desain meja-pertama (di mana kelas dihasilkan dari tabel) menyarankan model monolitik (meskipun selalu ada pertanyaan dan pandangan khusus), sementara desain kelas-pertama (di mana tabel dihasilkan dari kelas) menyarankan model OO yang lebih lakban, fleksibel. Saya agak tua-sekolah, lebih suka pendekatan pertama-tabel, tapi saya bisa melihat bagaimana pendekatan pertama-kelas akan menarik bagi beberapa orang.

— Robert Harvey

@Robert, itu bukan maksud saya untuk memunculkan "debat EF", saya hanya mengeluarkan satu kutipan dari halaman itu karena di situlah saya pertama kali mendengar argumen (dan saya tidak yakin apakah saya pernah mendengarnya) diekspresikan dengan jelas di tempat lain). Secara terpisah, saya tidak yakin saya setuju bahwa desain table-first sebenarnya mewakili model monolitik; database itu sendiri , tetapi hanya DBMS yang benar-benar sadar akan hal itu - bagian-bagian aplikasi yang berbeda cenderung hanya mengetahui tabel dan kueri tertentu yang menjadi sandarannya.

— Aaronaught

Menanggapi artikel EF Vote of No Confidence , Tim Mallalieu menulis:

Kami tidak merekomendasikan agar orang-orang kembali ke hari-hari ketika kami menginjili penggunaan XSD untuk "skema kanonik". Saya tidak percaya bahwa orang-orang berpikir bahwa ini bisa dilakukan. Apa yang kami yakini, bagaimanapun, adalah bahwa diinginkan untuk memiliki satu meta-model (EDM jika Anda mau) yang dengannya Anda dapat menggambarkan banyak model domain dan bahwa dengan memiliki tata bahasa tunggal kami dapat menyediakan satu set layanan umum pada setiap diberikan model domain.

Misalnya, pertimbangkan aplikasi yang akan ditulis terhadap database dengan 600 tabel. Apakah saya percaya bahwa aplikasi ini harus memiliki model tunggal dengan 600 Jenis Entitas di dalamnya? Tidak ... Selanjutnya, apakah saya percaya bahwa entitas domain tertentu (misalnya Pelanggan) hanya memiliki satu bentuk di aplikasi itu dan bahwa bentuk ini harus merupakan bentuk kanonik untuk seluruh Perusahaan? ... Heck no.

Artikel Wikipedia untuk Canonical Model merujuk hal-hal seperti Bus Layanan Perusahaan , Arsitektur Berorientasi Layanan , dan CORBA , hal-hal yang sepertinya tidak lagi dibicarakan. Mereka semua diajukan sebagai solusi untuk proliferasi data dan tantangan komunikasi perusahaan, Satu Cincin untuk Memerintah Mereka Semua. ^TM Apakah mereka berhasil? Atau apakah mereka jatuh karena berat badan mereka sendiri?

Anda meminta pengalaman pribadi, jadi saya akan memberikan satu. Dalam industri dirgantara kita banyak menggunakan telemetri. Salah satu tantangan dengan sistem telemetri adalah menemukan cara untuk rentang tes yang berbeda untuk berkomunikasi data uji satu sama lain dengan cara yang bermakna. Masalah itu tampaknya cukup sederhana, sampai Anda mencoba mendefinisikan kamus data dengan istilah umum.

Apa arti "ketinggian"? Apakah ketinggian di atas tanah, atau ketinggian di atas permukaan laut? Bagaimana jika Anda berbicara tentang kapal selam? Lalu dalamnya, bukan ketinggian. Bagi Angkatan Darat, kata "transmisi" memiliki arti yang berbeda ketika Anda merujuk pada antena parabola dibandingkan dengan kendaraan darat. Permukaan sayap yang menyebabkan pesawat terguling disebut "aileron" pada beberapa pesawat, dan "elevon" pada yang lain.

Itu hanya petunjuk di gunung masalah yang mengikuti. Meskipun ada standar untuk komunikasi data, setiap rentang tes berbeda, dan memiliki kebutuhan, tujuan, dan prioritas yang berbeda. Standar dapat berbeda bahkan di antara berbagai proyek pada rentang yang sama. Untuk alasan ini, rentang pengujian memahami bahwa solusi tidak akan datang dengan mengganti semuanya dengan sistem monolitik tunggal, tetapi dengan menyetujui protokol komunikasi sederhana dan menyediakan cara untuk menerjemahkan dari satu kosakata rentang ke yang lain.

Masalah yang dihadapi perusahaan besar serupa. Microsoft cenderung berpikir secara monolitik, tetapi itu karena perusahaan mereka, pada umumnya, monolitik. Segera setelah Anda perlu berkomunikasi antara perusahaan yang berbeda dengan budaya yang sangat berbeda dan cara berbisnis (atau bahkan antara departemen yang berbeda di perusahaan yang sama), Satu Cincin untuk Memerintah Mereka Semua. ^TM segera mulai rusak.

— Robert Harvey
sumber

Sangat menarik untuk mengetahui bahwa perancang Microsoft sendiri tidak merekomendasikan mega-model bersama; Sayangnya itulah tepatnya Linq to SQL dan EF dan banyak ORM lainnya cenderung digunakan. Apapun, masih ada banyak orang di luar sana yang mempromosikan konsep Model Canonical dan saya masih ingin tahu bagaimana tarifnya dalam praktik vs alternatif.

— Aaronaught

@Aaronaught: Lihat hasil edit saya.

— Robert Harvey

Ini edit yang bagus, dan FYI saya sudah memutarnya. Namun, saya sudah mengetahui banyak masalah ketidaksesuaian spesifik yang muncul ketika mencoba untuk mengkanoniskan suatu model; Saya sangat tertarik mempelajari pengalaman atau data jangka panjang tentang tim yang telah menginvestasikan waktu untuk menyelesaikan ketidaksesuaian tersebut, sehingga memiliki satu mapper per titik akhir (model akhir), vs. menginvestasikan waktu di akhir yang terpisah sebagai gantinya para pembuat peta, dan pendekatan mana yang benar-benar menghasilkan solusi dengan biaya terendah / kompleksitas terendah.

— Aaronaught

Atau untuk membuatnya lebih ringkas: Saya tahu bahwa banyak pekerjaan untuk membuat dan memelihara model kanonik, yang ingin saya ketahui adalah kapan (jika pernah) manfaatnya diamati lebih besar daripada biayanya.

— Aaronaught