도메인 주도 개발 시작하기 CH.6 ~ CH.7

 

 

 

 

 

 

Ch. 6 :  응용 서비스와 표현 영역 

 

 

6.1

• 표현 영역 
  • 사용자의 요청 해석 및 담당 응용 서비스 호출 
  • 응용 서비스가 요구하는 형식으로 사용자 요청을 변환 
  • 응용 서비스 호출 후 실행 결과를 사용자에게 맞는 형식으로 응답 
    • 덕분에, 응용 서비스가 표현 영역에 의존하지 않을 수 있음
• 응용 영역 
  • 실제 사용자가 원하는 기능을 제공 
    • 기능 실행에 필요한 인자를 메서드 인자로 받고 실행 결과 리턴 

 

6.2

• 응용 서비스 
  • 사용자(클라이언트)가 요청한 기능 실행 
  • 역할
    • 기능 실행 
      • 레포지터리에서 도메인 객체를 가져와 사용 
      •  도메인 객체를 사용
        • => 도메인 영역과 표현 영역을 연결해주는 창구 역할 
          • 응용 서비스가 복잡하다면, 도메인 로직을 구현하고 있는지 파악해보아야 함 
          • 도메인 로직을 분산해서 구현하면, 코드 품질 문제 발생 및 반복 구현 가능성이 높아짐 
          • 응집도가 떨어지고 코드 변경이 어려워짐 
    • 트랜잭션 처리 
      • 도메인의 상태 변경할 수 있도록 
    • 접근 제어
    • 이벤트 처리 

 

6.3

• 응용서비스 
  • 도메인 영역을 연결하는 매개체 역할 
    • => 파사드와 같은 역할 
  • 구현 방법
    • 도메인별 한 응용 서비스에 모든 기능 구현 
      • 동일 로직 코드 중복 제거 용이 
      • 클래스 크기가 커짐 
      • 연관성이 적은 코드가 한 서비스에 위치하게 됨 
    • 구분되는 기능별로 응용 서비스 따로 구현 
      • => 한 응용 서비스에서 한 개 내지 2~3개의 기능만을 구현 
      • 클래스 개수는 많아지지만, 코드 품질을 일정 수준으로 유지 가능
      • 필요한 의존 객체만 포함하기 때문에 다른 기능을 구현한 코드에 영향 받지 않음 
        • 동일한 코드가 많아진다면, 별도 클래스에 로직을 구현해서 코드 중복 방지 가능 
          • ex) ServiceHelper 
  • 인터페이스
    • 필요한 상황 
      • 구현 클래스가 여러개인 경우 
        • => 거의 없음 
        • 인터페이스가 명확하게 필요하기 전까지 응용 서비스에 대한 인터페이스를 작성하는 것이 필수는 아님 
  • 메서드 파라미터와 데이터 전달 
    • 요청 파라미터가 두개 이상 존재하면 별도 클래스를 사용하는 것이 편리 
  • 결과 전달
    • 응용 서비스가 애그리거트 자체를 리턴하면 코딩은 편하지만, 도메인 로직 실행을 으용 서비스와 표현 영역 두곳에서 할 수 있게 됨 
    • => 응집도를 높이기 위해서 필요한 데이터만 반환하자!
  • 응용 서비스의 파라미터에 표현 영역과 관련된 타입을 사용하면 안됨 
    • 표현 영역의 응집도 저하 
    • 코드 유지 보수 비용 증가 
    • => 서비스 메서드의 파라미터와 리턴 타입으로 표현 영역의 구현 기술을 사용하지 않아야 함 
  • 트랜잭션 
    • 프레임 워크가 제공하는 트랜잭션 기능을 적극 사용하자! 

 

6.4

• 표현 영역 
  • 책임 
    • 사용자가 시스템을 사용할 수 있는 흐름을 제공하고 제어 
      • 사용자가 요청한 내용을 응답으로 제공 
    • 사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공 
      • 사용자의 요청에 맞게 응용서비스에 기능 실행 호출 및 형식 변환 담당 
    • 사용자의 세션 관리  
      • 사용자의 연결 상태 관리 

 

6.5

• 값 검증 
  • 표현 영역과 응용 서비스에서 모두 수행 가능 
    • 원칙적으로 모든 값에 대한 검증은 응용 서비스에서 처리 
      • 에러 코드를 모아 하나의 익셉션으로 발생 시킬수도 있음 
    • 표현 영역에서 필수 값 검증 
      • 값의 형식을 검증 
    • => 즉, 표현영역에서는 값의 형식을 검사하고 응용 서비스는 논리적 오류를 검사 

 

6.6

• 권한 검사 수행 가능 영역 
  • 표현 영역 
    • 서블릿 필터 등 
      • 인증 여부 검사, 권한 검사 
      • ex) 스프링 시큐리티 프레임워크 
    • 인증 정보를 생성하고 웹 접근 제어 
  • 응용 서비스 
    • URL만으로 접근 제어가 불가능하고 메서드 단위의 권한 검사가 필요한 경우 
      • => AOP로도 권한 검사가 가능함 
        • ex) @PreAuthorize
  • 도메인  
    • 도메인 객체 수준의 권한 검사 로직은 도메인 별로 다르므로 도메인에 맞게 보안 프레임워크를 확장하려면 프레임워크에 대한 높은 이해 필요 

 

6.7

• 조회 전용 서비스 
  • 트랜잭션이 필요하지 않은 경우 표현 영역에서 바로 조회 전용 기능 사용 가능 
  • 응용 서비스가 사용자 요청 기능을 실행하는데 별 기능을 하지 않는다면 굳이 필요 없음 

 

 

 

 

Ch. 7 :  도메인 서비스 

 

7.1 - 7.2

• 여러 애그리거트가 필요한 기능 구현  
  •  한 애그리거트가 필요한 데이터를 모두 가지도록 구현 
    • 한 애그리거트에 넣기 애매한 도메인 기능이 억지로 특정 애그리거트에 구현되면 안됨 
    • 애그리거트가 자신의 책임 범위를 넘어서는 기능을 구현하게 됨 
    • 외부 의존도가 높아지게 됨 
    • 수정이 어려워짐 
    • 범위를 넘어서는 도메인 개념이 파악이 어려워짐 
  • 도메인 기능을 별도로 도메인 서비스로 구현 
    • 도메인 영역에 위치한 도메인 로직을 표현할 때 사용 
      • 한 애그리거트에 넣기 애매한 도메인 개념을 구현 
    • 도메인의 애그리거트나 밸류와 달리 상태없이 로직만 구현 
      • 구현하는데 필요한 상태는 다른 방법으로 전달 받음 
    • 애그리거트 객체에 도메인 서비스를 전달하는 것은 응용 서비스 책임 
      • 도메인 서비스 객체를 애그리거트에 파라미터로 전달하거나 의존 주입하면 애그리거트가 일부 기능만 필요하면서 데이터와도 관계없는 도메인 서비스에 의존하게 됨 
      • -> 도메인 서비스의 기능을 실행할 때 애그리거트를 넘겨주는 방법을 사용할 수 있음 
    • 응용 로직은 수행하지 않고 도메인 로직만 수행함 
      • 트랜잭션과 같은 처리는 하지 않음 
      • => 애그리거트의 상태를 변경하거나 값을 계산하는 경우는 도메인 로직으로 판단하자! 
    • 외부 연동 도메인 서비스도 될 수 있음 
      • ex) 역할 관리 외부 시스템을 연동하여 권한 확인 
      • 인터페이스로 구현하고 실제 구현체인 클래스는 인프라스트럭쳐 영역에 위치하여 검사 기능 구현 
    • 도메인 서비스 로직이 고정되어 있지 않은 경우도 도메인 서비스자체를 인터페이스로 구현할 수 있음 
      • 실제 구현체는 intra 영역 
      • => 특정 구현 기술에 의존하거나 외부 시스템의 API를 실행한다면 도메인 영역의 도메인 서비스는 인터페이스로 추상화하자! 
      • => 특정 구현에 종속되는 것을 방지하고 테스트가 용이해짐