Câu trả lời:
Các dòng có thể hơi mờ, nhưng tôi thấy nó theo cách này:
Một lớp / giao diện Dịch vụ cung cấp cho khách hàng cách tương tác với một số chức năng trong ứng dụng. Điều này thường là công khai, với một số ý nghĩa kinh doanh. Ví dụ: một TicketingServicegiao diện có thể cho phép bạn buyTicket, sellTicketv.v.
Một lớp người trợ giúp có xu hướng bị ẩn khỏi máy khách và được sử dụng nội bộ để cung cấp một số công việc tấm nồi hơi không có ý nghĩa miền kinh doanh. Ví dụ: giả sử bạn muốn chuyển đổi một ngày thành dấu thời gian để lưu nó vào kho dữ liệu cụ thể của bạn. Bạn có thể có một lớp tiện ích được gọi DateConvertorvới một convertDateToTimestampphương thức thực hiện quá trình xử lý này.
Các dịch vụ không chỉ đơn giản được kết hợp chặt chẽ với DAO, đó là một mô hình sử dụng / thuật ngữ rộng hơn so với sự kiên trì
Các lớp của trình trợ giúp không vi phạm SRP nếu được mã hóa theo nguyên tắc đó. Nghĩa là, mỗi phương thức nên thực hiện một điều và một điều tốt, lớp nên thực hiện một loại trợ giúp tiện ích, (ví dụ: chuyển đổi ngày) và thực hiện tốt điều đó.
Không phải là một định nghĩa khoa học, nhưng nói chung của tôi là một lớp dịch vụ có một số ngữ cảnh trong ứng dụng trong khi những người trợ giúp thì chung chung hơn và không quan tâm họ đang giúp ứng dụng nào.
Đối với tôi, tôi đi theo định nghĩa của Eric Evans vềservice cái gì đó giống như thế này:
Nói chung, trong một hệ thống được thiết kế tốt, hầu hết các lớp (trong Mô hình miền) có trách nhiệm hoặc chức năng khá rõ ràng ở chỗ chúng xử lý một thực thể cụ thể hoặc tập hợp các thực thể trong mô hình.
I E
Khi bạn có chức năng không thuộc về bất kỳ thực thể cụ thể nào, có thể khó tìm được vị trí chính xác cho vị trí đó. Tức là một cái gì đó gói gọn một quá trình bao gồm cả AccountAND a Customer.
Vì vậy, đó là nơi servicexuất hiện. Đó là nơi bạn đặt mã trong Mô hình miền nhưng không tự nhiên thuộc về một thực thể / thành phần này.
Tôi nghĩ về helpermột loại lớp chiến lược. Đối với tôi, đây là nơi để đặt mã cần được sử dụng lại bởi các lớp khác nhau nhưng có thể không hoàn toàn ngồi tốt như các phương thức trừu tượng bên trong hệ thống phân cấp của các lớp sử dụng nó. Cá nhân tôi thấy thuật ngữ này helperhơi mơ hồ và không thực sự có chúng trong mô hình của tôi. Mặc dù chúng tồn tại trong các thư viện mà tôi sử dụng.
Lớp dịch vụ: Chứa logic nghiệp vụ.
Lớp người trợ giúp: lớp này là một loại thành phần có thể tái sử dụng.
Bạn trộn lẫn hai hiệu trưởng không liên quan. Các dịch vụ và lớp người trợ giúp không được kết nối. Đặc biệt là thuật ngữ "Lớp dịch vụ" là sai lệch - Tôi nghĩ rằng bạn đang đề cập đến một "Dịch vụ" ở mức độ trừu tượng cao hơn các lớp. Một dịch vụ được đặc trưng thông qua
"một cơ chế cho phép truy cập vào một hoặc nhiều khả năng, trong đó quyền truy cập được cung cấp bằng giao diện được chỉ định và được thực hiện phù hợp với các ràng buộc và chính sách theo quy định của mô tả dịch vụ."
Định nghĩa này thay đổi một chút tùy thuộc vào bối cảnh của bạn. Tuy nhiên, điểm quan trọng là thuật ngữ "dịch vụ" ở mức độ trừu tượng , mức độ kiến trúc và kiến thức tên miền . "Lớp người trợ giúp" là một mẫu thiết kế (mặc dù đó là mẫu chống khi chúng có xu hướng phát triển thành các lớp của blob hoặc thượng đế) đề cập đến một lớp bao gói các hoạt động chung (lưu ý rằng đây là mức độ trừu tượng thấp hơn và được kết nối đến kiến thức ứng dụng / giải pháp ). Tôi nhận thức được thực tế rằng gần như không có phần mềm nào không chứa bất kỳ loại lớp trợ giúp nào, nhưng vẫn là một thực tế tồi.
Một điều cần cảnh giác là nhiều định nghĩa về 'dịch vụ' trong DDD:
Dịch vụ ứng dụng: Chúng nằm trong lớp ứng dụng và giao tiếp với miền dữ liệu và lớp, chúng là giao diện mà qua đó các hệ thống / UI bên ngoài tương tác với hệ thống DDD.
Dịch vụ miền: Điều này có thể được sử dụng bởi miền hoặc lớp ứng dụng và chứa logic nghiệp vụ không khớp với một thực thể cụ thể.
Dịch vụ cơ sở hạ tầng: Chúng được sử dụng bởi miền để liên lạc với các tài nguyên bên ngoài.
Các lớp của trình trợ giúp có xu hướng chứa các đoạn mã hoặc thuật toán sẽ được nhiều thực thể sử dụng lại, vì vậy không thể thực sự đi vào các thực thể mà không vi phạm nguyên tắc DRY. Chúng có lẽ là gần nhất với Dịch vụ miền, ở chỗ chúng sắp xếp thực hiện cùng một mục đích (ngoại trừ logic kinh doanh từ các thực thể) nhưng chúng làm điều đó vì những lý do khác nhau.