Saya mencoba merancang aplikasi yang memiliki domain bisnis yang kompleks dan persyaratan untuk mendukung REST API (tidak sepenuhnya REST, tetapi berorientasi sumber daya). Saya mengalami beberapa masalah dengan cara mengekspos model domain dengan cara yang berorientasi sumber daya.
Di DDD, klien dari model domain harus melalui lapisan 'Layanan Aplikasi' prosedural untuk mengakses fungsionalitas bisnis apa pun, yang diterapkan oleh Entitas dan Layanan Domain. Misalnya ada layanan aplikasi dengan dua metode untuk memperbarui entitas Pengguna:
userService.ChangeName(name);
userService.ChangeEmail(email);
API Layanan Aplikasi ini memperlihatkan perintah (kata kerja, prosedur), bukan status.
Tetapi jika kita juga perlu menyediakan API RESTful untuk aplikasi yang sama, maka ada model sumber daya Pengguna, yang terlihat seperti ini:
{
name:"name",
email:"email@mail.com"
}
API berorientasi sumber daya memperlihatkan status , bukan perintah . Ini menimbulkan kekhawatiran berikut:
setiap operasi pembaruan terhadap API REST dapat memetakan ke satu atau lebih panggilan prosedur Layanan Aplikasi, tergantung pada properti apa yang sedang diperbarui pada model sumber daya
setiap operasi pembaruan terlihat seperti atom ke klien REST API, tetapi tidak diimplementasikan seperti itu. Setiap panggilan Layanan Aplikasi dirancang sebagai transaksi terpisah. Memperbarui satu bidang pada model sumber daya dapat mengubah aturan validasi untuk bidang lain. Jadi kita perlu memvalidasi semua bidang model sumber daya bersama-sama untuk memastikan bahwa semua panggilan Layanan Aplikasi potensial valid sebelum kita mulai membuatnya. Memvalidasi satu set perintah sekaligus jauh lebih mudah daripada melakukan satu per satu. Bagaimana kita melakukannya pada klien yang bahkan tidak tahu perintah individual ada?
memanggil metode Layanan Aplikasi dalam urutan berbeda mungkin memiliki efek yang berbeda, sementara REST API membuatnya tampak seperti tidak ada perbedaan (dalam satu sumber daya)
Saya bisa memunculkan masalah yang lebih mirip, tetapi pada dasarnya mereka semua disebabkan oleh hal yang sama. Setelah setiap panggilan ke Layanan Aplikasi, keadaan sistem berubah. Aturan tentang apa itu perubahan yang valid, serangkaian tindakan yang dapat dilakukan entitas dalam perubahan berikutnya. API berorientasi sumber daya mencoba menjadikan semuanya tampak seperti operasi atom. Tetapi kerumitan melintasi celah ini harus pergi ke suatu tempat, dan tampaknya sangat besar.
Selain itu, jika UI lebih berorientasi pada perintah, yang sering terjadi, maka kita harus memetakan antara perintah dan sumber daya di sisi klien dan kemudian kembali ke sisi API.
Pertanyaan:
- Haruskah semua kompleksitas ini ditangani oleh lapisan pemetaan REST-to-AppService (tebal)?
- Atau apakah saya kehilangan sesuatu dalam pemahaman saya tentang DDD / REST?
- Mungkinkah REST tidak praktis untuk mengekspos fungsionalitas model domain pada tingkat kompleksitas (yang cukup rendah) tertentu?