답변:
선이 약간 흐려질 수 있지만 다음과 같이 보입니다.
서비스 클래스 / 인터페이스는 클라이언트가 응용 프로그램의 일부 기능과 상호 작용할 수있는 방법을 제공합니다. 이것은 일반적으로 몇 가지 비즈니스 의미를 가진 공개입니다. 예를 들어, TicketingService인터페이스를 사용하여 buyTicket등을 수행 할 수 있습니다 sellTicket.
도우미 클래스는 클라이언트에서 숨겨지는 경향이 있으며 내부적으로 비즈니스 영역 의미가없는 보일러 플레이트 작업을 제공하는 데 사용됩니다. 예를 들어, 특정 데이터 스토어에 저장하기 위해 날짜를 타임 스탬프로 변환하려고한다고 가정 해 봅시다. 이 처리를 수행 DateConvertor하는 convertDateToTimestamp메소드로 호출 된 유틸리티 클래스가있을 수 있습니다 .
서비스는 단순히 DAO와 밀접하게 연결되어 있지 않으며 지속성보다 광범위한 용어 / 사용 패턴입니다.
헬퍼 클래스는 해당 원칙에 따라 코딩 된 경우 SRP를 위반하지 않습니다. 즉, 각 메소드는 한 가지 일만 잘 수행해야하며 클래스는 한 가지 유형의 유틸리티 도움말 (예 : 날짜 변환)을 수행해야합니다.
저에게는 Eric Evans의 정의service 가 다음과 같습니다.
일반적으로 잘 설계된 시스템에서 대부분의 클래스 (도메인 모델)는 모델의 특정 엔터티 또는 엔터티 집합을 처리한다는 분명한 책임 또는 기능을 가지고 있습니다.
즉
특정 엔티티에 속하지 않는 기능이있는 경우 올바른 위치를 찾기가 어려울 수 있습니다. 즉 AccountAND와 a 를 모두 포함하는 프로세스를 캡슐화하는 것입니다 Customer.
A는 어디 그래서, 그건 service제공됩니다. 당신은 도메인 모델에 있지만 자연스럽게 하나의 엔티티 / 구성 요소 또는 다른에 속하지 않는 코드를 삽입하는 곳이 있습니다.
저는 helper일종의 전략 클래스 라고 생각 합니다. 나에게 다양한 클래스에서 재사용 해야하는 코드를 넣을 수있는 곳이지만 코드를 사용하는 클래스의 계층 구조 내에서 추상 메소드로는 잘 맞지 않을 수 있습니다. 개인적으로 나는 그 용어 helper가 약간 모호하여 실제로 내 모델에 포함되어 있지 않습니다. 그것들은 내가 사용하는 라이브러리에 존재하지만.
관련이없는 두 명의 주체를 혼합했습니다. 서비스와 도우미 클래스가 연결되어 있지 않습니다. 특히 "서비스 클래스"라는 용어는 오해의 소지가 있습니다. 클래스보다 추상화 수준이 높은 "서비스"를 말하는 것 같습니다. 서비스는 다음을 통해 특징 지어집니다
"하나 이상의 기능에 액세스 할 수있는 메커니즘. 규정 된 인터페이스를 사용하여 액세스가 제공되며 서비스 설명에 지정된 제약 조건 및 정책과 일치하게 수행됩니다."
이 정의는 상황에 따라 약간 변경됩니다. 그러나 중요한 점은 "서비스"라는 용어가 추상적 인 수준 , 아키텍처 및 도메인 지식 수준 이라는 점입니다 . "헬퍼 클래스"는 일반적인 조작을 캡슐화하는 클래스 (이는 낮은 레벨의 추상화에 있으며 연결되어 있음 에 유의) 받는 응용 프로그램 / 솔루션 지식 ). 나는 어떤 종류의 도우미 클래스를 포함하지 않는 소프트웨어가 거의 없다는 사실을 알고 있지만 여전히 나쁜 습관입니다.
조심해야 할 한 가지는 DDD에서 'service'의 여러 정의입니다.
응용 프로그램 서비스 : 응용 프로그램 계층에 있으며 도메인 및 데이터 계층과 통신하며 외부 시스템 / UI가 DDD 시스템과 상호 작용하는 인터페이스입니다.
도메인 서비스 : 도메인 또는 응용 프로그램 계층에서 사용할 수 있으며 하나의 특정 엔터티에 꼭 맞지 않는 비즈니스 논리를 포함합니다.
인프라 서비스 : 도메인에서 외부 리소스와 통신하는 데 사용됩니다.
헬퍼 클래스는 여러 엔티티에서 재사용 할 코드 또는 알고리즘을 포함하는 경향이 있으므로 DRY 원칙을 위반하지 않으면 실제로 엔티티에 들어갈 수 없습니다. 그들은 같은 목적을 달성한다는 점에서 (도메인의 비즈니스 로직을 외부화하는) 도메인 서비스에 가장 가깝지만 다른 이유로 수행합니다.