Apakah praktik buruk bagi layanan untuk berbagi database di SOA?

Saya baru-baru ini membaca Hohpe dan Woolf's Enterprise Integration Patterns, beberapa buku Thomas Erl tentang SOA dan menonton berbagai video dan podcast oleh Udi Dahan et al. pada sistem CQRS dan Event Driven.

Sistem di tempat kerja saya menderita kopling tinggi. Meskipun setiap sistem secara teoritis memiliki database sendiri, ada banyak yang bergabung di antara mereka. Dalam praktiknya ini berarti ada satu database besar yang digunakan semua sistem. Misalnya, ada satu tabel data pelanggan.

Banyak dari apa yang saya baca tampaknya menyarankan data yang dinormalisasi sehingga setiap sistem hanya menggunakan basis datanya, dan setiap pembaruan ke satu sistem disebarkan ke semua yang lain menggunakan pesan.

Saya pikir ini adalah salah satu cara menegakkan batas-batas dalam SOA - setiap layanan harus memiliki database sendiri, tetapi kemudian saya membaca ini:

/programming/4019902/soa-joining-data-across-multiple-services

dan ini menunjukkan bahwa ini adalah hal yang salah untuk dilakukan.

Memisahkan basis data sepertinya merupakan cara yang baik untuk memisahkan sistem, tetapi sekarang saya agak bingung. Apakah ini rute yang baik untuk ditempuh? Pernahkah disarankan agar Anda memisahkan basis data, katakanlah layanan SOA, konteks Berbatas DDD, aplikasi, dll?

Decoupling hanya berfungsi jika memang ada pemisahan. Pertimbangkan jika Anda memiliki sistem pemesanan:

• Tabel: PELANGGAN
• Tabel: PESANAN

Jika hanya itu yang Anda miliki, tidak ada alasan untuk memisahkan mereka. Di sisi lain, jika Anda memiliki ini:

• Tabel: PELANGGAN
• Tabel: PESANAN
• Tabel: CUSTOMER_NEWSLETTER

Kemudian Anda dapat berargumen bahwa ORDER dan CUSTOMER_NEWSLETTER adalah bagian dari dua modul yang benar-benar terpisah (pemesanan dan pemasaran). Mungkin masuk akal untuk memindahkan ini ke dalam basis data yang terpisah (satu untuk setiap tabel), dan kedua modul berbagi akses ke tabel PELANGGAN yang umum dalam basis datanya sendiri.

Dengan melakukan itu Anda menyederhanakan setiap modul, tetapi Anda meningkatkan kompleksitas lapisan data Anda. Ketika aplikasi Anda tumbuh semakin besar, saya bisa melihat keuntungan untuk memisahkan. Akan ada semakin banyak "pulau data" yang benar-benar tidak memiliki hubungan satu sama lain. Namun, akan selalu ada beberapa data yang memotong semua modul.

Keputusan untuk menempatkan mereka dalam database fisik yang berbeda biasanya akan didasarkan pada kendala dunia nyata seperti frekuensi cadangan, pembatasan keamanan, replikasi ke lokasi geografis yang berbeda, dll. Saya tidak akan memisahkan tabel menjadi database fisik yang berbeda hanya karena memisahkan masalah. Itu dapat ditangani lebih sederhana dengan skema atau pandangan berbeda.

Di tempat saya bekerja, kami memiliki ESBdimana 6 aplikasi berbeda (atau harus saya katakan "titik akhir") terhubung. Keenam aplikasi tersebut bekerja dengan 3 skema Oracle berbeda pada 2 instance database. Beberapa aplikasi ini hidup berdampingan dalam skema yang sama bukan karena mereka terkait tetapi karena infrastruktur basis data kami dikelola oleh penyedia eksternal dan mendapatkan skema baru hanya membutuhkan waktu lama (juga, kami tentu saja tidak memiliki akses DBA) ... Itu benar-benar membutuhkan waktu begitu lama sehingga pada satu titik kami berpikir untuk menggunakan kembali skema yang ada "sementara" untuk dapat melanjutkan pembangunan. Untuk menerapkan "pemisahan" data, nama tabel diawali, misalnya "CST_" untuk pelanggan. Selain itu, kami harus bekerja dengan skema yang karena beberapa alasan yang valid kami tidak dapat mengubah absolut ... Aneh, saya tahu. Tentu saja, seperti yang selalu terjadi, "sementara"

Aplikasi kami yang berbeda terhubung ke skema database masing-masing dan bekerja dengan paket PL / SQL mereka sendiri dan kami benar-benar melarang diri untuk berinteraksi langsung dengan tabel / data yang berada di luar domain aplikasi kami.

Ketika salah satu aplikasi yang terhubung ke ESB membutuhkan informasi di luar dari domainnya, ia memanggil layanan terkait pada ESB untuk mendapatkan data, bahkan jika informasi itu sebenarnya dalam skema yang sama, yang secara teori memerlukan sedikit pernyataan bergabung dalam salah satu permintaan SQL .

Kami melakukan itu agar dapat membagi domain aplikasi kami menjadi skema / basis data yang berbeda, dan agar layanan pada ESB tetap berfungsi dengan baik saat itu terjadi (ini akan segera Natal, kami membagikan jari)

Sekarang, ini mungkin terlihat aneh dan mengerikan dari luar tetapi ada alasan untuk itu dan saya hanya ingin berbagi pengalaman konkret ini untuk menunjukkan kepada Anda bahwa satu atau lebih database tidak begitu penting. Tunggu, ini! , untuk banyak alasan (+1 untuk Scott Whitlock, lihat paragraf terakhir tentang cadangan dan sedemikian rupa sehingga mya membawa Anda ke dalam kesulitan). saya bukan DBA. Pada akhirnya, semua basis data Anda adalah milik "perusahaan datawarehouse" Anda, bukan?

Akhirnya, saya tidak akan mengulangi paragraf terakhir Scott Whitlock, khususnya ini

Saya tidak akan memisahkan tabel menjadi database fisik yang berbeda hanya karena memisahkan masalah.

sangat penting. Jangan lakukan itu jika tidak ada alasan.

Saya telah melihat mimpi terburuk yang mungkin terjadi dalam arsitektur perangkat lunak karena integrasi data, dan senjata terbaik melawan jenis kekacauan ini yang saya temui sejauh ini id DDD-Style Bounded Contexts. Yang tidak jauh dari "SOA dilakukan dengan benar", dalam arti tertentu.

Namun, data itu sendiri bukan cara terbaik untuk menyerang masalah. Seseorang harus fokus pada perilaku yang diharapkan / dibutuhkan dan membawa data ke tempat yang penting. Kita mungkin akhirnya memiliki beberapa duplikasi dengan cara ini, tetapi ini biasanya bukan masalah dibandingkan dengan blok untuk evolusi sistem yang hampir selalu dikaitkan dengan arsitektur data-terintegrasi.

Sederhananya: jika Anda mencari sistem yang digabungkan secara longgar, jangan tetap digabungkan pada data. Gunakan sistem enkapsulasi weel dan saluran komunikasi yang terstruktur dengan baik di antara keduanya, bertindak sebagai "lingua franca".

Memisahkan basis data dan menjaga data tetap konsisten di antara mereka adalah tugas tingkat ahli. Sangat mudah untuk mendapatkan kesalahan dan berakhir dengan masalah duplikat dll, bahwa sistem saat ini dirancang untuk dihindari. Terus terang, mengambil sistem kerja dan melakukan ini cukup banyak jaminan untuk memperkenalkan bug baru tanpa nilai nyata bagi pengguna.

Jika dilakukan dengan benar, memisahkan masalah bisnis ke dalam basis data yang berbeda (atau setidaknya skema yang berbeda) adalah suatu kebajikan .

Silakan lihat deskripsi Martin Fowler tentang Pola CQRS :

Ketika kebutuhan kita menjadi lebih canggih, kita terus menjauh dari [memperlakukan sistem informasi seperti data CRUD] ... Perubahan yang diperkenalkan CQRS adalah untuk membagi model konseptual menjadi model terpisah untuk pembaruan dan tampilan ... Ada ruang untuk variasi yang cukup besar sini. Model dalam-memori dapat berbagi basis data yang sama, dalam hal ini basis data bertindak sebagai komunikasi antara kedua model. Namun mereka juga dapat menggunakan basis data terpisah , yang secara efektif membuat basis data sisi-permintaan dengan Database Reporting real-time. Dalam hal ini perlu ada beberapa mekanisme komunikasi antara dua model atau database mereka.

Dan Prinsip Arsitektur NServiceBus :

Pemisahan Permintaan Perintah

Solusi yang menghindari masalah ini memisahkan perintah dan permintaan di tingkat sistem, bahkan di atas klien dan server. Dalam solusi ini ada dua "layanan" yang menjangkau klien dan server - satu bertanggung jawab atas perintah (membuat, memperbarui, menghapus), yang lain bertanggung jawab atas permintaan (baca). Layanan ini hanya berkomunikasi melalui pesan - satu tidak dapat mengakses database dari yang lain ...

Dan Segregasi Command and Query Responsibility (CQRS)

Pemisahan Tanggung Jawab Komando dan Pertanyaan

Sebagian besar aplikasi membaca data lebih sering daripada menulis data. Berdasarkan pernyataan itu, itu akan menjadi ide yang baik untuk membuat solusi di mana dengan mudah Anda dapat menambahkan lebih banyak database untuk dibaca, kan? Jadi bagaimana jika kita membuat database yang didedikasikan hanya untuk membaca? Bahkan lebih baik; bagaimana jika kita mendesain basis data sedemikian sehingga lebih cepat untuk membacanya? Jika Anda mendesain aplikasi Anda berdasarkan pola yang dijelaskan dalam arsitektur CQRS, Anda akan memiliki solusi yang scalable dan cepat dalam membaca data.