Saya mengerti bahwa Perintah tidak boleh mengembalikan apa pun.
Itu satu pandangan, tapi tidak sepenuhnya dibuat-buat. Pertimbangkan menulis (PUT, POST, HAPUS) dalam HTTP - semua pesan ini adalah perintah, dalam arti bahwa mereka adalah pesan dengan permintaan bahwa status sumber daya berubah, namun semuanya mengembalikan respons.
Jadi, bagaimana Anda menangani kesalahan di luar Command Bus? (Misalnya, pengguna mendaftar 1 detik sebelumnya dengan nama pengguna / email yang sama).
Bagaimana Anda tahu bahwa perintah itu gagal, dan bagaimana Anda tahu kesalahannya?
Jadi dalam kasus di mana Anda berkomunikasi secara langsung dengan pengendali perintah, pesan yang dikembalikan adalah cara yang masuk akal untuk mengakui bahwa perintah telah diterima dan diproses.
Jika Anda menggunakan sepotong middleware, seperti bus, yang mencegah Anda berkomunikasi langsung dengan target, maka saya akan menyarankan agar Anda melihat ke pola pesan asinkron - bagaimana Anda mendapatkan penangan perintah untuk mengirim pesan kembali ke penelepon?
Satu ide adalah berlangganan hasil dari perintah; ini meminjam dari beberapa gagasan dalam Pola Integrasi Perusahaan Hohpe. Gagasan dasarnya adalah bahwa, karena klien terbiasa dengan pesan perintah yang dikirim, ia berada pada posisi yang tepat untuk berlangganan pesan baru yang diterbitkan sebagai konsekuensi dari pesan perintah tersebut. Penangan perintah, setelah menyimpan data ke dalam buku catatan, menerbitkan peristiwa yang mengumumkan bahwa perubahan itu berhasil, dan klien berlangganan peristiwa-peristiwa tersebut - mengenali peristiwa yang benar dengan mempertimbangkan kebetulan berbagai pengidentifikasi dalam pesan (causation id, id korelasi , dan sebagainya).
Pendekatan alternatif sedikit lebih langsung. Satu akan memasukkan dalam pesan panggilan balik, yang dapat dipanggil oleh penangan perintah setelah pesan berhasil ditangani.
Alternatif yang sangat mirip adalah dengan menyimpan ruang dalam pesan perintah untuk penangan perintah untuk menulis pengakuan - karena klien sudah memiliki pesan perintah yang dipermasalahkan, sirkuit sudah lengkap. Pikirkan " janji " atau " masa depan yang bisa diselesaikan". Pesan itu memberi tahu penangan perintah di mana harus menulis pengakuan; melakukan hal tersebut memberi sinyal kepada klien (kait hitung mundur) bahwa pengakuan tersedia.
Dan tentu saja, Anda memiliki opsi tambahan untuk menghapus middleware yang tampaknya menghalangi cara melakukan hal yang benar.
Misalnya, pengguna mendaftar 1 detik sebelumnya dengan nama pengguna / email yang sama
Jika Anda menangani pendaftaran pengguna dengan tenang, itu tidak akan selalu menjadi kesalahan - pengulangan pesan sampai respons diamati adalah cara yang umum untuk memastikan setidaknya sekali pengiriman.