【정리】『실천 도메인 구동 설계』: 7. 서비스

서비스란?

도메인 별 작업을 수행하는 상태가없는 작업

유비쿼터스 언어 준수

어떤 작업이 Aggregate 또는 Value Object 메서드가 아니라고 느껴지면 Service로 만들면 좋을 것입니다

.

Domain Service가 아닌 것

서비스 지향 아키텍처

메시지 지향 미들웨어

응용 프로그램 서비스 (이것은 도메인 서비스 클라이언트가 됨)

입도가 큰 것 (coarse-graind)

원격 실행 가능 (remote-capable)

무게 등급 (heavyweight)

트랜잭션 작업이있는 것 (transactional operation)

Domain Service인 것

도메인의 중요한 처리 및 변형 작업.
이미 있는 Entity나 Value Object에 맞지 않는 조작.

중요한 비즈니스 처리

도메인 객체를 다른 도메인 객체로 변형

입력에 둘 이상의 도메인 객체를 수신하여 값 (Value)을 계산합니다

도메인 서비스의 과도한 사용

도메인 서비스의 과도한 사용은 도메인 모델 결핍증 (Anemic Domain Model)입니다.

왜 서비스가 필요한지 잘 생각하십시오 :
"이 행동은 단순히 Entity에 넣을 수 없습니까?"

만약 이유가

그것은 Entity의 단일 책임 (Single Responsibility)을 위반하기 때문에

클라이언트가 복잡해지기 때문에

도메인 관련 지식이 클라이언트로 유출되기 때문에

등등인 경우에, 응답은 "서비스를 만들 것이다."

Entity에 있는 static method는 Service가 되는 플래그.

Service 구현의 이로하

서비스를 Separated Interface로 설정하는 것이 좋습니다

인터페이스는 도메인 레이어에 정의됩니다

.

그리고 단 하나의 조작을 갖게 한다

기술 구현은 Infrastructure Layer에서 만들 수 있습니다

구현 클래스 이름은 구현의 특성을 표현합니다 (단순히 -Impl 또는 Default- 대신)

구현은 유비쿼터스 언어을 명시 적으로 표현한다!

Separated Interface 해야 할 때, 그렇지 않을 때

해야 할 때

서비스에 여러 구현 (폴리 모픽)

기술 구현 (예 : 암호화 기술 및 인프라 계층의 리포지토리에 의존)

서비스 인스턴스화 방법을 숨기고 싶을 때

그렇지 않을 때

Separated Interface는 항상 필요한 것은 아닙니다. 보통 클래스를 Domain Layer로 만드는 것만으로 충분할 때도 있다.

서비스의 다형성이 필요하지 않은 경우

도메인 관련 작업 만 포함하는 경우

Dependency Injection이나 Service Factory가 Service의 인스턴스화 방법을 은폐하고 있을 때.

만약 구현 클래스가, 인터페이스명에 -Impl나 Default-와 같은 접사를 붙이고 있을 뿐이라면, 그것은 Separated Interface가 불필요하다고 하는 신호.

서비스 테스트

서비스를 어떻게 사용하는지 시연할 수 있는 모범적인 테스트를 제공하는 것.