Menerapkan pendekatan CQRS dan CQS dalam layanan mikro DDD di eShopOnContainers
Tip
Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.
Desain layanan mikro pemesanan di aplikasi referensi eShopOnContainers didasarkan pada prinsip CQRS. Namun, ini menggunakan pendekatan paling sederhana, yang hanya memisahkan kueri dari perintah dan menggunakan database yang sama untuk kedua tindakan.
Inti dari pola tersebut, dan poin penting di sini, adalah bahwa kueri bersifat idempoten: tidak peduli berapa kali Anda mengkueri sebuah sistem, status sistem tersebut tidak akan berubah. Dengan kata lain, kueri bebas efek samping.
Oleh karena itu, Anda dapat menggunakan model data "baca" yang berbeda dari model domain "tulis" logika transaksi, meskipun pemesanan layanan mikro menggunakan database yang sama. Oleh karena itu, ini adalah pendekatan CQRS yang disederhanakan.
Di sisi lain, perintah, yang memicu transaksi dan pembaruan data, mengubah status dalam sistem. Dengan perintah, Anda harus berhati-hati saat berhadapan dengan kompleksitas dan aturan bisnis yang terus berubah. Pada titik ini, Anda ingin menerapkan teknik DDD untuk memiliki sistem model yang lebih baik.
Pola DDD yang disajikan dalam panduan ini tidak boleh diterapkan secara universal. Pola ini memiliki batasan pada desain Anda. Batasan tersebut memberikan manfaat seperti kualitas yang lebih tinggi dari waktu ke waktu, terutama dalam perintah dan kode lain yang memodifikasi status sistem. Namun, batasan tersebut menambah kompleksitas dengan lebih sedikit manfaat untuk membaca dan mengkueri data.
Salah satu pola tersebut adalah pola Agregat, yang kami periksa lebih lanjut di bagian selanjutnya. Secara singkat, dalam pola Agregat, Anda memperlakukan banyak objek domain sebagai satu unit sebagai hasil dari hubungannya di domain. Anda mungkin tidak selalu mendapatkan keuntungan dari pola ini dalam kueri; ini dapat meningkatkan kompleksitas logika kueri. Untuk kueri baca-saja, Anda tidak mendapatkan keuntungan dalam memperlakukan beberapa objek sebagai satu Agregat. Anda hanya mendapatkan kompleksitas.
Seperti yang ditunjukkan pada Gambar 7-2 di bagian sebelumnya, panduan ini menyarankan penggunaan pola DDD hanya di area transaksi/pembaruan layanan mikro (yaitu, seperti yang dipicu oleh perintah). Kueri dapat mengikuti pendekatan yang lebih sederhana dan harus dipisahkan dari perintah, mengikuti pendekatan CQRS.
Untuk menerapkan "sisi kueri", Anda dapat memilih di antara banyak pendekatan, dari ORM lengkap seperti EF Core, proyeksi AutoMapper, prosedur tersimpan, tampilan, tampilan materialisasi, atau ORM mikro.
Dalam panduan ini dan di eShopOnContainers (khususnya layanan mikro pemesanan), kami memilih untuk menerapkan kueri lurus menggunakan ORM mikro seperti Dapper. Panduan ini memungkinkan Anda menerapkan kueri apa pun berdasarkan pernyataan SQL untuk mendapatkan performa terbaik, berkat kerangka kerja ringan dengan sedikit overhead.
Saat Anda menggunakan pendekatan ini, setiap pembaruan pada model yang memengaruhi cara entitas dipertahankan ke database SQL juga memerlukan pembaruan terpisah untuk kueri SQL yang digunakan oleh Dapper atau pendekatan terpisah (non-EF) lainnya untuk kueri.
Pola CQRS dan DDD bukan arsitektur tingkat atas
Penting untuk dipahami bahwa CQRS dan sebagian besar pola DDD (seperti lapisan DDD atau model domain dengan agregat) bukan gaya arsitektur, tetapi hanya pola arsitektur. Layanan mikro, SOA, dan arsitektur berbasis peristiwa (EDA) adalah contoh gaya arsitektur. Mereka menggambarkan sistem dari banyak komponen, seperti banyak layanan mikro. Pola CQRS dan DDD menjelaskan sesuatu di dalam satu sistem atau komponen; dalam hal ini, sesuatu di dalam layanan mikro.
Konteks Terikat (BC) yang berbeda akan menggunakan pola yang berbeda. Mereka memiliki tanggung jawab yang berbeda, dan mengarah pada solusi yang berbeda. Perlu ditekankan bahwa memaksa pola yang sama di semua tempat dapat menyebabkan kegagalan. Jangan gunakan pola CQRS dan DDD di semua tempat. Banyak subsistem, BC, atau layanan mikro lebih sederhana dan dapat diimplementasikan dengan lebih mudah menggunakan layanan CRUD sederhana atau menggunakan pendekatan lain.
Hanya ada satu arsitektur aplikasi: arsitektur sistem atau aplikasi menyeluruh yang Anda rancang (misalnya, arsitektur layanan mikro). Namun, desain setiap Konteks Terikat atau layanan mikro dalam aplikasi tersebut mencerminkan tradeoff dan keputusan desain internalnya sendiri pada tingkat pola arsitektur. Jangan mencoba menerapkan pola arsitektur yang sama dengan CQRS atau DDD di semua tempat.
Sumber daya tambahan
Martin Fowler. CQRS
https://martinfowler.com/bliki/CQRS.htmlGreg Young. Dokumen CQRS
https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdfUdi Dahan. CQRS terklarifikasi
https://udidahan.com/2009/12/09/clarified-cqrs/
