6주차 - 06. 응용 서비스와 표현 영역

[DaehunGwak]

진도

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

일정

• 2022.01.29.(일) 19:00

[DaehunGwak]

느낀점

전반적으로 실제적으로 구현했을 때 사소한 고민이라고 생각했던 ‘도메인에 구현해도 괜찮을까?’, ‘DTO는 어디까지 경계를 가져야할까?’, ‘검증은 어디까지 해야할까?’ 등에 대해서 다시 생각해보고 정리할 수 있게됨

개인 정리 노트

https://first-diadem-378.notion.site/6-13dcece951a34aec8dd839a0998c1126

[kdg0209]

표현 영역과 응용 영역

---

• 표현 영역의 사용자의 요청을 해석합니다. 사용자에의해 웹 브라우저로부터 받은 요청은 표현 영역에 전달되며 URL, 파라미터, 쿠키, 헤더의 정보를 이용해 사용자가 실행하고자 하는 기능을 판별합니다.

• 응용 영역은 사용자가 원하는 기능을 제공하는 영역입니다. 응용 영역은 표현 영역으로부터 데이터를 받아 사용자가 원하는 기능을 실행합니다.

응용 서비스의 역할

---

• 응용 서비스는 사용자가 요청한 기능을 실행합니다. 응용 서비스는 사용자의 요청을 처리하기 위해 리포지터리에서 도메인 객체를 가저와 사용합니다.

• 응용 서비스의 로직이 복잡하다면 도메인 로직의 일부를 구현하고 있을 가능성이 높으며 이로 인해 코드 중복, 로직 분산으로 인한 낮은 응집도를 가질 수 있습니다. 또한 응용 서비스는 트랜잭션 처리도 담당하며 일관성이 깨지지 않도록 주의해야 합니다.

도메인 로직이 노출된 응용 서비스

public class UserService {

    public void changePassword(String oldPassword, String newPassword) {
        User user = userRepository.findById(1L).orElseThrow();

        // 도메인 로직 노출
        if (!passwordEncoder.matches(oldPassword, user.getPassword())) {
            throw new IllegalArgumentException();
        }

        user.changePassword(oldPassword, newPassword);
    }
}

생각해본 코드 하지만 PasswordEncoder의 위치를 어디에 둬야하는가에 대한 의문이 있습니다.

@Entity
@Table
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Embedded
    private Password password;

    public User(Password password) {
        this.password = password;
    }

    public void changePassword(String oldPwd, String newPwd) {
        password.changePassword(oldPwd, newPwd);
    }
}

@Embeddable
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Password {

    private static final PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

    private String password;

    public Password(String password) {
        setPassword(password);
    }

    public void changePassword(String oldPwd, String newPwd) {
        if (!matchPassword(oldPwd)) {
            throw new IllegalArgumentException();
        }
        setPassword(newPwd);
    }

    private void setPassword(String password) {
        if (!StringUtils.hasText(password)) {
            throw new IllegalArgumentException();
        }
        this.password = passwordEncoder.encode(password);
    }

    private boolean matchPassword(String inputPassword) {
        return passwordEncoder.matches(inputPassword, this.password);
    }
}

public class UserService {

    public void changePassword(String oldPassword, String newPassword) {
        User user = userRepository.findById(1L).orElseThrow();
        user.changePassword(oldPassword, newPassword);
    }
}

응용 서비스의 구현

---

• 하나의 응용 서비스 클래스에 회원 도메인의 모든 기능 구현

---> 하나의 응용 서비스에 도메인의 모든 기능(CRUD)을 구현하면 중복되는 코드를 private 메서드를 사용하여 메서드 추출 기법을 통해 중복 코드를 제거할 수 있습니다. 하지만 하나의 클래스는 여러 책임을 가지게 되고 코드의 크기가 증가하게 됩니다.

• 구분되는 기능별로 응용 서비스 클래스를 따로 구분하여 구현

---> 하나의 클래스는 2~3개의 기능을 구현하며 해당 기능 구현에 필요한 의존 객체만 필요로 함으로 다른 기능을 구현한 코드에 영향을 받지 않습니다. 다만 클래스의 개수가 많아지고, 중복 코드 발생시 유틸 클래스 등을 활용해야 합니다.

• 응용 서비스의 인터페이스와 클래스

---> UserService 인터페이스와 이를 구현한 UserService가 필요한지에 대한 논쟁입니다. 인터페이스가 필요한 상황은 구현 클래스가 여러개 존재하며 런타임 시에 구현 클래스를 교체해야할 때입니다. 그런데 응용 서비스는 런타임에 교체하는 경우가 거의 없으며, 인터페이스와 구현 클래스를 따로 관리하면 클래스만 많아지고 전체적인 구조가 복잡해집니다.

[chilling1000]

1. 표현 영역(Presentation)과 응용 영역(Application)은 우리가 흔히 알고 있는 Controller, Service 이다.

2. 도메인 로직은 코드의 응집성을 위해, 도메인에만 있어야 한다. 만일, 응용 영역에도 같이 있다면, 코드가 복잡해진다. 한편으로는 DDD가 아닐 때는 응용 영역에 전부 넣는 게 유지보수 하기에 더 좋기도 하다.

3. 응용 서비스에서 구현할 메소드의 크기가 너무 크다면, 유즈 케이스를 최대한 나눠서 작성하거나, 따로 최대한 분리시켜서 하는 게 좋다.

4. 중복 로직이 발생할 때는 private 메소드로 분리시켜서 필요한 곳에 사용할 수 있다. 대표적인 예가 find() 메소드를 사용할 때이다. 우리가 흔히 알고 있는 ArrayList 이런 자료구조를 보면, get(index)를 여러 메소드 Ex) Set() 등등 에서 사용되는 것을 볼 수 있다. 그 이유는 보일러 플레이트 코드를 줄이기 위함이기도 하다. 하지만, 단순히 한줄로만 실행되는 코드라면, 굳이 분리시켜야 하는 합리적인 이유가 있을까 라고 봤을 때, 그렇게 나쁘다고 생각되진 않는다. 왜냐하면, 그 한줄을 네이밍해서 사용한다면, 비록 메소드 스택을 한 번씩 더 타야하는 수고로움이 발생하지만, 코드를 읽는 관점에서는 조금 더 효율적일 수 있기 때문이다.

5. 응용 서비스단에서 인터페이스를 구현한 구체 클래스를 본 적이 많지만, 1:1로 대응된다면 도저히 사용할 가치가 없다고 판단되며, 구현 클래스가 여러 개일 경우에 사용하는 의미가 있다고 생각한다.

   
   public TestInterface<T> {
   void create(T t);
   T retrieve(int id);
   int remove(int id);
   int update(int index, T t);
   }
   위처럼, 다양한 기능을 수행하는 인터페이스이다.
   반면에, 아래는 1:1로만 기능을 수행하는 인터페이스이다.

public TestInterface { void doSomething(Objecb obj); }

향후, 여러 기능을 수행할 인터페이스로 발전한다면, 이렇게 선언해서 사용하는 게 합리적이지만, 그냥 관행을 따르는 것이라면, 추천하진 않는다.
추가로, 토비의 스프링의 경우 위와 같이 1:1로 대응되는 Interface Impl 클래스를 선언해서 사용하는 것을 합리적이라고 함.
우리가 저번 챕터에서 배운 Data JPA 기술이 김영한 강의의 내용에 나온 기술에 비하면, 비효율적이라는 것을 알 수 있듯이, 
시간이 지나면서 트렌드가 바뀔 수도 있고, 다시 바뀐 트렌드가 제자리에 오는 경우가 있다.

6. 응용 서비스의 메소드 리턴 타입이 void일 경우, 보통 리다이렉션으로 사용되는 경우가 많다. 예를 들면, 계정 비밀번호를 변경 후,
리다이렉션이 되는데 여기에 추가할 리턴값을 생각해보자면, 거의 없는 게 대부분이다. 그리고 실행 메소드가 실패되더라도,
그것은 예외 발생으로 인한 실패이니, 오류 메시지로 리턴된다.

7. 표현 영역의 책임은 사용자의 값을 검증하고, 응용 서비스에게 검증된 값을 전달 후, 데이터를 받아서 다시 사용자에게 제공하는 역할을 한다. 그래서 HTTP로 넘어온 값들 Ex) HttpServletRequest 등 을 받으면, 곧바로 응용 서비스에 전달하는 것이 아니라, 검증해서 보낸다. 여기서 검증이란, 빈값이 있는지 확인하는 용도이기도 하고, 파라미터로 받은 객체를 그대로 전달하는 것을 방지하는 용도이기도 하다.

추가로, 값 검증을 서비스단에서 하는 방법도 있지만, 개인적으로는 표현 영역에서 처리하는 게 합리적이라고 생각한다.

[developer-wonjin]

6장 응용서비스와 표현영역

1. 표현영역

• 사용자의 요청을 해석
  • URL
  • 요청파라미터(GET, POST 방식)
  • 쿠키
  • 헤더
• 알맞은 컨트롤러로 요청 분기
  • 알맞은 기능을 실행할 수 있도록 응용서비스 실행
• (프레임워크의 기능) 파라미터 바인딩
  • 요청파라미터를 DTO의 필드에 자동 바인딩
  • 응용서비스가 요구하는 DTO를 준비
• 응용역역을 의존함 [그림2.4]

1.1. 표현영역의 값리턴

강의 실전 스프링부트와 JPA활용2 - API개발과 성능최적화

• 엔티티를 그대로 리턴하면 안됨.
• 엔티티의 필드명 변경시 API스펙이 변경된다.
• 클라이언트에서 잘 사용하고 있다가 에러를 마주한다.
  • 따라서, 이미 한번 공개된 API는 스펙을 변경할 수 없게 해야한다.

1.2. 표현영역만 다뤄야하는 자원 : 세션, 쿠키

• 아래 코드와 같이 서블릿 자원을 응용영역에 전달하게 되면 문제가 발생한다.

public class XXXService{
    public void XXXmethod(HttpServletRequest request){
        HttpSession session = request.getSession();
        session.setAttribute("auth", new Authentication(id));
    }
}

1. 응용영역 -> 표현영역 방향으로 잘못된 방향으로 의존이 생겨버림
   • 서블릿자원을 참조하는 것만으로 의존이 생긴다?
   • Controller가 Service를 멤버필드로 갖는 것과 다른 의미의 의존인가?
2. 응용서비스가 테스트하기 어려워진다. (서블릿 자원까지도 테스트를 위한 준비를 해놔야함)
3. 표현영역 소스코드만으로 표현영역의 상태(세션, 쿠키)값의 변경을 파악하기 어려움
   • 응용영역 소스코드까지 들어가봐야 암

1.3. 이벤트

추후 뒷 장에서....

2. 응용영역

• 사용자에게 제공할 실제기능
• Command, Query 기능으로 크게 두개로 나눌 수 있음
  • CQRS는 인프라, API, 메소드 레벨을 달리하여 바라볼 수 있다
• 표현영역의 구현기술에 의존적이지 않다.
  • 표현영역 구현기술에 관심없다
  • 표현영역에 MVC웹요청(Thymeleaf)인지, 모바일의RestAPI요청인지 관심없다.

2.1 역할

public MemberService{
    public Long register(MemberDTO m){
        Member member = memberRepository.dtoToEntity(m); 
        memberRepository.save(member); //1. 레포지토리를 통한 도메인객체 조회, 저장

        //... 2. 얻은 도메인객체를 사용
        // 3. 도메인 객체간의 흐름제어

        return member.getId();
    }

    //4. 다중 DML 건들에 대한 트랜잭션 처리
    @Transactional
    public void makeBlackConsumer(Long[] ids){
        for(Long id : ids){
            Member member = memberRepository.findById(id);
             member.makeBlackConsumber();
        }
    }
}

• 위의 3번 역할로 서비스는 소스코드가 간결하다

2.2. 응용서비스는 되도록 잘게 나누자

• 연관성 없는 코드를 함께 보는 것은 괴롭다

• 응용서비스를 잘 나눠놨는데, 갑자기 연관성을 발견했다면?

  • Helper클래스를 도입

  public final class MemberServiceHelper{
      public static Member findExistingMember(MemberRepository repo, Long memberId){
          //...
      }
  }
  
  import static com.myshop.member.application.MemberServiceHelper.*;
  public class ChangePasswordService{
      private MemberRepository repo;
  
      public void changePassword(Long memberId, Stirng curPw, String newPw){
          Member member = findExistingMember(repo, memberId);
          //...
      }
  }

2.3. 응용서비스의 인터페이스

• [개발순서]
  • 표현영역 -> 응용영역
  • 아직 개발되지 않은 응용서비스에 대해 인터페이스(메소드 시그니처) 스펙만 정의한다.
  • 표형영역을 테스트하기 위해 위 인터페이스 스펙에 맞춰input, output이 정해진 Mock객체를 생성하여 미래에 실제 구현될 클래스를 대체한다.
  • 근데 인터페이스 없어도 Mock객체는 만들 수 있어서 굳이 인터페이스 필요하겠냐
  • 응용영역 -> 표현영역
  • 책표현이 쫌 이상하네;;

3. 유효성검사 (입력값, 비즈니스로직)

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 (유효성 파트만 5시간)

• 표현영역에서 담당할 검사 : 입력값 (Hibernate validation 어노테이션으로 간단히 해결)
  • 필수여부
  • 값의형식 : 숫자, 이메일
  • 범위 : min, max
• 응용영역에서 담당할 검사
  • 비즈니스로직을 수행중에 발생하는 논리적 오류검사

4. 접근제어 Access Control

• 표현영역

  • Filter 에서 인증객체 존재여부 확인
  • Controller 에서 인가 처리 ADMIN / DEV / MANAGER / USER

• 응용서비스

  • MANAGER 권한을 지녔어도 프로젝트에 소속된 직원이 아니면 제한주기
  • 프로젝트 소속 여부를 서비스계층에서 DB조회를 통해 알아야함

• 도메인 단위 권한검사

  • 책의 예제가 과연 개별 도메인 단위라고 할 수 있을까?

  public class DeleteArticleService{
      public void delete(String userId, Long articleId){
          Article article = articleRepository.findById(articleId);
          checkArticleExistence(article);
          permissionSerice.checkDeletePermission(userId, artilce);
          article.markDeleted();
      }
  }

5. 조회전용 기능

• 응용서비스 필요없음.
• Repository는 애그리거트를 위한 용도로만 사용해야 함
• 따라서, 애그리거트간 조인, 통계쿼리로 조회를 할 경우 Spring-Data-Jpa가 아닌 EntityManager를 직접 사용한다.
• p.162

[progress0407]

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

Intro

이번 장에도 특별히 건질 것 같아 보이는 부분이 없었다... ㅠ

6.1 표현 영역과 응용 영역

• HTTP 요청 실행
  • URL, Query Parameter, Cookie, Header 등
• HTML or JSON 응답
  • HTML: CSR
  • JSON: SSR

6.2 응용 서비스의 역할

• 응용 서비스가 HttpServletRequest 등 표현 영역을 의존하지 않게 설계 하자!
  • import 문을 보도록 하자!
• 도메인 로직을 서비스에 퍼트리지 않게 한다.

6.3 응용 서비스의 구현

MemberService의 비밀번호 변경 로직을 ChangePasswordService에 놓았다. 하지만 공감되지 않는다... 이미 코드에 나와있는 데로, Member가 Password를 가지고 있고, member에게 Password 변경 권한을 위임하는 것으로 충분하지 않을까...

6.4 표현 영역

• 화면 제공
• 요청 처리 및 결과 전달
• 사용자 세션 관리

6.5 값 검증

• Spring의 BindingValidation을 이용
  • 영한님의 API 예외 처리...
• 이렇게 사용할 경우 타임리프 등 화면에 오류를 전달할 때 사용할 수 있다!
  • 예전에 가볍게 토이로 타임리프 사용했는데... 생각보다는 편하지는 않았다.
  • 화면을 서버 렌더링 없이 보여줄 수 있다고는 하는데... 개발하다 보면 사실상 서버의 흐름을 항상 타야 한다.

6.6 권한 검사

스프링 시큐리티에 대한 높은 이해도가 없다면... 차라리 직접 구현하는게 나을 것 같다

• AOP + 리플렉션

6.7 조회 전용 기능과 응용 서비스

CQRS 얘기다 !