Saya sedang mengerjakan sebuah proyek di mana kami mencoba menerapkan desain berbasis domain dan REST untuk arsitektur berorientasi layanan. Kami tidak khawatir tentang kepatuhan REST 100%; mungkin akan lebih baik untuk mengatakan kami mencoba membangun HTTP API yang berorientasi pada sumber daya (~ Level 2 dari model maturitas REST Richardson). Namun demikian, kami mencoba untuk menjauh dari penggunaan permintaan HTTP gaya-RPC, yaitu kami mencoba untuk mengimplementasikan kata kerja HTTP kami menurut RFC2616 daripada menggunakan POST
melakukan IsPostalAddressValid(...)
, misalnya.
Namun, penekanan pada hal ini tampaknya mengorbankan upaya kami untuk menerapkan desain berbasis domain. Dengan hanya GET
, POST
, PUT
, DELETE
dan beberapa lainnya metode jarang digunakan, kita cenderung untuk membangun layanan cruddy, dan layanan cruddy cenderung memiliki model domain anemia.
POST
: Menerima data, memvalidasinya, membuangnya ke data. GET
: Ambil data, kembalikan. Tidak ada logika bisnis yang nyata di sana. Kami juga menggunakan pesan (peristiwa) antara layanan, dan menurut saya sebagian besar logika bisnis akhirnya dibangun di sekitar itu.
Apakah REST dan DDD tegang pada tingkat tertentu? (Atau apakah saya salah mengerti sesuatu di sini? Apakah kita mungkin melakukan sesuatu yang salah?) Apakah mungkin untuk membangun model domain yang kuat dalam arsitektur berorientasi layanan sambil menghindari panggilan HTTP gaya-RPC?