Layanan Mikro & model Canonical

Ketika saya membaca tentang layanan microser di situs ini , saya menemukan pernyataan di bawah ini. Apa yang dimaksud dengan skema kanonik? Bukankah itu sama dengan model domain?

Pola Arsitektur Layanan Microsoft juga menolak bagian lain dari SOA, seperti konsep skema kanonik.

— Punter Vicky
sumber

Apakah Anda tahu sumber pernyataan itu? (untuk tujuan menghubungkan)

— Jack

Tentu Jack, ada di sini - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

Saya kira artikel Wikipedia ini adalah apa yang Anda cari. Namun, saya tidak menemukan artikel yang mudah dimengerti.

— Arseni Mourzenko

Terima kasih @ArseniMourzenko. Saya percaya bahkan dalam arsitektur microservice, permintaan dan respons harus mematuhi beberapa model data. Belum dapat memahami mengapa ini disebut ditolak oleh arsitektur layanan mikro.

— Punter Vicky

Beberapa model data ya, tetapi bagi saya, artikel tersebut merujuk pada model data "bersama" atau "umum" antara 2 layanan atau lebih. Skema Canonical adalah pola yang dimaksudkan untuk menyimpan layanan dari transformasi data runtime. "Bahasa" yang umum di antara layanan. Jadi sepertinya artikel ini menekankan pada kemandirian total MS dari "ekosistem" tempat tinggalnya. Ambil contoh penyebutan yang dilakukan untuk ESB. ESB biasanya menuntut model data perusahaan (pesan) yang akan umum untuk semua orang di bus. MS menolak untuk dilampirkan ke penyempitan sistem eksternal.

— Laiv

Jawaban:

Permintaan maaf sebelumnya karena mengandalkan komentar @ArseniMourzenko, tetapi begitu saya mulai membaca Wikipedia, saya langsung mengerti apa artinya Skema Canonical .

Di sini komentar OP yang berfokus pada keraguan nyata

Saya percaya bahkan dalam arsitektur microservice, permintaan dan respons harus mematuhi beberapa model data.

Beberapa model data ya, tetapi tampaknya artikel tersebut merujuk pada model data "bersama" atau "umum" antara 2 layanan atau lebih.

The Canonical Skema adalah pola dimaksudkan untuk menyelamatkan jasa dari dalam transformasi data yang runtime. Ini juga menyelamatkan Anda dari duplikasi kode. Tetapi Anda kemudian menggabungkan layanan Anda ke model data eksternal juga. (Lihat diagram di halaman Wikipedia yang ditautkan di atas)

Ini semacam "bahasa" yang umum di antara layanan.

Jadi sepertinya artikel ini menekankan pada kemandirian total MS dari "ekosistem" tempat tinggalnya.

Ambil contoh penyebutan yang dilakukan untuk ESB.

Mereka juga sangat menghindari menggunakan ESB dan malah mengimplementasikan fungsionalitas seperti ESB dalam layanan microser sendiri.

ESB biasanya menuntut model data perusahaan (pesan) yang akan umum untuk semua orang yang melekat pada bus.

Jadi, kembali ke artikel, tampaknya penulis menunjuk ke fakta bahwa MS menolak untuk dilampirkan ke sistem eksternal (dan kendala mereka) .

— Laiv
sumber

Terima kasih @Lav. Saya akan menghadiahkan hadiah dalam 9 jam - jadi membatasi saya :)

— Punter Vicky

Semua layanan Microsoft adalah tentang kohesi ketat dan kopling longgar. Di dalam layanan mikro, Anda memiliki ikatan yang erat, tetapi di antara layanan mikro, Anda memiliki sambungan longgar dan karenanya Anda ingin menghindari skema bersama atau kontrak data. Jika Anda menemukan bahwa Anda memiliki layanan microser yang membuat panggilan sinkron satu sama lain dengan cara yang menuntut mereka berbagi skema umum, itu bisa menjadi indikasi bahwa Anda telah mendefinisikan batas layanan Anda secara tidak benar.

Layanan Microsoft harus diselaraskan erat dengan Konteks Terikat, dalam bahasa Desain Berbasis Domain.

— pnschofield
sumber

If you find that you have microservices making synchronous calls. Tidak harus panggilan tak sinkron. Itu bisa terjadi juga dengan pesan asinkron ESB. Saya pikir ini fokus pada fakta untuk digabungkan ke skema bersama atau kontrak data. Saya berasumsi bahwa dalam arsitektur MS, harus dihindari komunikasi P2P antara layanan. Komunikasi harus terjadi melalui aplikasi alih-alih lapisan internal (lapisan layanan dalam) atau eksternal (ESB, antrian, dll.)

— Laiv