Jawaban:
Garis-garisnya bisa sedikit buram, tetapi saya melihatnya seperti ini:
Kelas / antarmuka layanan menyediakan cara klien untuk berinteraksi dengan beberapa fungsionalitas dalam aplikasi. Ini biasanya bersifat publik, dengan beberapa makna bisnis. Misalnya, TicketingServiceantarmuka mungkin memungkinkan Anda buyTicket, sellTicketdan seterusnya.
Kelas pembantu cenderung disembunyikan dari klien dan digunakan secara internal untuk menyediakan beberapa pekerjaan pelat ketel yang tidak memiliki arti domain bisnis. Misalnya, katakanlah Anda ingin mengonversi tanggal menjadi stempel waktu untuk menyimpannya ke datastore khusus Anda. Anda mungkin memiliki kelas utilitas yang dipanggil DateConvertordengan convertDateToTimestampmetode yang melakukan pemrosesan ini.
Layanan tidak hanya dipasangkan dengan DAO, ini adalah istilah / pola penggunaan yang lebih luas daripada ketekunan
Kelas pembantu tidak melanggar SRP jika diberi kode sesuai dengan prinsip itu. Artinya, setiap metode harus melakukan satu hal dan satu hal dengan baik, kelas harus melakukan satu jenis bantuan utilitas, (mis. Konversi tanggal) dan melakukannya dengan baik.
Bukan definisi ilmiah, tetapi pendapat umum saya adalah kelas layanan memiliki beberapa konteks dalam aplikasi sedangkan pembantu lebih umum dan tidak peduli aplikasi apa yang mereka bantu.
Bagi saya, saya menggunakan definisi Eric Evansservice yang kira-kira seperti ini:
Secara umum, dalam sistem yang dirancang dengan baik, sebagian besar kelas (dalam Model Domain) memiliki tanggung jawab atau fungsi yang cukup jelas karena mereka berurusan dengan entitas atau kumpulan entitas tertentu dalam model.
yaitu
Ketika Anda memiliki fungsionalitas yang bukan milik entitas tertentu, mungkin sulit untuk menemukan tempat yang tepat untuk duduk. Yaitu sesuatu yang merangkum proses yang melibatkan kedua AccountDAN a Customer.
Jadi, di situlah servicemasuk. Di sinilah Anda meletakkan kode yang ada dalam Model Domain tetapi tidak secara alami milik satu entitas / komponen atau lainnya.
Saya menganggap helperkelas strategi. Bagi saya ini adalah tempat untuk meletakkan kode yang perlu digunakan kembali oleh berbagai kelas tetapi mungkin tidak cukup baik sebagai metode abstrak di dalam hierarki kelas yang menggunakannya. Secara pribadi saya menemukan istilah helperagak kabur dan tidak benar-benar memilikinya dalam model saya. Meskipun mereka ada di perpustakaan yang saya gunakan.
Kelas Layanan: Berisi logika bisnis.
Helper Class: kelas ini adalah salah satu jenis komponen yang dapat digunakan kembali.
Anda mencampuradukkan dua kepala sekolah yang tidak terkait. Layanan dan Kelas Penolong tidak terhubung. Terutama istilah "Kelas Layanan" menyesatkan - saya pikir Anda mengacu pada "Layanan" yang berada pada tingkat abstraksi yang lebih tinggi daripada kelas. Suatu layanan dicirikan melalui
"sebuah mekanisme untuk memungkinkan akses ke satu atau lebih kemampuan, di mana akses disediakan menggunakan antarmuka yang ditentukan dan dilaksanakan konsisten dengan kendala dan kebijakan sebagaimana ditentukan oleh deskripsi layanan."
Definisi ini sedikit berubah tergantung pada konteks Anda. Namun, titik kritisnya adalah bahwa istilah "layanan" ada pada tingkat abstrak , tingkat arsitektur dan pengetahuan domain . "Helper Class" adalah pola desain (meskipun anti-pola karena mereka cenderung berevolusi ke kelas gumpalan atau dewa) merujuk pada kelas yang merangkum operasi generik (perhatikan bahwa ini adalah pada tingkat abstraksi yang lebih rendah dan terhubung untuk pengetahuan aplikasi / solusi ). Saya menyadari fakta bahwa hampir tidak ada perangkat lunak yang tidak mengandung kelas helper, tapi tetap saja, ini praktik yang buruk.
Satu hal yang perlu diwaspadai adalah definisi berganda dari 'layanan' di DDD:
Layanan aplikasi: Ini duduk di lapisan aplikasi dan berkomunikasi dengan domain dan lapisan data, mereka adalah antarmuka di mana sistem eksternal / UI berinteraksi dengan sistem DDD.
Layanan Domain: Ini dapat digunakan oleh domain atau lapisan aplikasi, dan berisi logika bisnis yang tidak cocok dengan satu entitas tertentu.
Layanan Infrastruktur: Ini digunakan oleh domain untuk berkomunikasi dengan sumber daya eksternal.
Kelas pembantu cenderung berisi potongan kode atau algoritma yang akan digunakan kembali oleh banyak entitas, jadi tidak bisa benar-benar masuk ke entitas tanpa melanggar prinsip KERING. Mereka mungkin paling dekat dengan Layanan Domain, dalam arti mereka memenuhi tujuan yang sama (mengeksternalkan logika bisnis dari entitas) tetapi mereka melakukannya untuk alasan yang berbeda.