Відповіді:
Рядки можуть бути трохи розмитими, але я бачу це так:
Клас обслуговування / інтерфейс надає клієнту можливість взаємодіяти з деякими функціональними можливостями програми. Це, як правило, публічно, має деяке ділове значення. Наприклад, TicketingServiceінтерфейс може дозволити вам buyTicket, sellTicketі так далі.
Клас помічників, як правило, прихований від клієнта і використовується внутрішньо, щоб забезпечити деяку роботу плит котла, що не має значення для ділової галузі. Наприклад, скажімо, що ви хотіли перетворити дату в часову позначку, щоб зберегти її у вашому конкретному сховищі даних. Ви могли б мати клас утиліти DateConvertorз convertDateToTimestampметодом , який виконує цю обробку.
Послуги не просто щільно поєднані з DAO, це більш широкий термін / модель використання, ніж наполегливість
Класи помічників не порушують SRP, якщо їх кодують відповідно до цього принципу. Тобто кожен метод повинен робити одне і одне, добре, клас повинен виконувати один тип допомоги утиліти (наприклад, перетворення дати) і робити це добре.
Не наукове визначення, але в моєму загальному розумінні клас обслуговування є певним контекстом у програмі, тоді як помічники є більш загальними і не байдуже, яким додаткам вони допомагають.
Для мене я розумію визначення Еріка Еванса,service яке є приблизно таким:
Як правило, у добре розробленій системі більшість класів (у Доменній моделі) несуть цілком чітку відповідальність або функцію в тому, що вони мають справу з конкретною сутністю або набором сутностей у моделі.
тобто
Якщо у вас є функціонал, який не належить жодному конкретному об'єкту, може бути важко знайти правильне місце для нього. Тобто те , що укладає в собі процес , який включає в себе одночасно Accountі А Customer.
Отже, саме там serviceпоступає. Тут ви ставите код, який знаходиться в доменній моделі, але, природно, не належить до тієї сутності / компонента чи іншої.
Я вважаю helperтакий клас стратегії. Для мене це місце, щоб поставити код, який потребують повторного використання різними класами, але він може не дуже добре відповідати абстрактним методам всередині ієрархії класів, які ним користуються. Особисто я вважаю цей термін helperтрохи невиразним і насправді їх немає в моїй моделі. Хоча вони існують у бібліотеках, якими я користуюсь.
Клас обслуговування: містить бізнес-логіку.
Клас помічників: цей клас є одним із типів багаторазового використання.
Ви змішали двох непов'язаних принципів. Послуги та Класи помічників не підключені. Особливо, термін "Клас обслуговування" вводить в оману - я думаю, ви маєте на увазі "Сервіс", який знаходиться на більш високому рівні абстракції, ніж класи. Послуга характеризується наскрізь
"механізм для доступу до однієї або декількох можливостей, коли доступ надається за допомогою встановленого інтерфейсу і виконується відповідно до обмежень та політики, визначених в описі послуги."
Це визначення дещо змінюється залежно від вашого контексту. Однак критичним моментом є те, що термін "послуга" знаходиться на абстрактному рівні , рівні архітектури та знань про домен . "Клас помічників" - це модель дизайну (навіть незважаючи на те, що це антитіла, оскільки вони, як правило, розвиваються до класів Блоба або Бога), посилається на клас, який інкапсулює загальні операції (зауважте, що це знаходиться на нижчому рівні абстракції і пов'язане до знань про застосування / рішення ). Мені відомо про той факт, що майже не існує програмного забезпечення, яке не містить будь-якого класу помічників, але все-таки це погана практика.
Варто бути обережним - це декілька визначень поняття "послуга" в DDD:
Служба прикладних програм: Вони сидять у рівні програми та спілкуються з доменом та рівнем даних, вони є інтерфейсом, через який зовнішні системи / інтерфейс взаємодіють із системою DDD.
Служба доменів: Це може використовуватися доменом або додатком рівня та містити бізнес-логіку, яка не вписується в одну конкретну сутність.
Служба інфраструктури: вони використовуються доменом для зв'язку з зовнішніми ресурсами.
Класи помічників, як правило, містять фрагменти коду або алгоритми, які будуть повторно використані декількома сутностями, тому реально не можуть перейти в сутності, не порушуючи принцип DRY. Вони, мабуть, найближчі до Доменних служб, оскільки вони начебто виконують ту саму мету (екстерналізація ділової логіки від юридичних осіб), але роблять це з різних причин.