자바스프링 개발자를 위한 실용주의 6. 안티패턴

스마트UI 패턴

스마트 UI 패턴을 정의하자면 다음과 같다.

“데이터 입출력, 비즈니스로직, 데이터베이스 통신 등 모두 UI레벨에서 처리하는 것.”

 

백엔드 개발자 입장에서 UI는 컨트롤러가 될 수 있다. 즉, 컨트롤러에 지나치게 많은 로직이 들어있는 경우라고 볼 수 있다. 이러한 맥락으로 본다면 스마트 컨트롤러라고 부를 수도 있다.

@RestController
@RequiredArgsConstructor
public class MemberController {

    private final MemberService memberService;
	private final MemberService memberRepository;
    
    @GetMapping
    public Result modifyMember(String id, String changeName) {
		// .. 검증
		// .. 조회
		// .. 수정
		// .. 등등
    }
}

여기서 “스마트”는 똑똑하다는 것이 아닌 비꼬는 표현이다.

엔터프라이즈급 프로젝트들은 거대하고 복잡하다. 그렇기 떄문에 적절한 레이어에 알맞는 로직을 작성해야 기능을 이해하는데 용이하며 유지보수가 좋아질 것이다. 또한 객체지향적인 코드가 만들어 지려면 위와 같은 안티패턴은 피해야 한다.

 

레어이드 아키텍처

이후 8장에서 레이어드 아키텍처를 자세히 다룬다. 때문에 계층에서 해야 할 일을 숙지하고 넘어가는 정도로 한다.

 

해당 주제에서 저자는 호소한다.

“제발 비즈니스 로직을 도메인이 처리하게 해주세요.”

 

이 내용을 이해해보자.

 

우리는 스마트 UI패턴을 사용하지 않는다. 하지만 해당 개념을 무의식적으로 서비스 레이어에 적용하고 있다. 이를 “트랜잭션 스크립트“ 이라고 부른다.

 

아래 예제를 보자 Controller의 역할은 분리됐지만, 많은 로직이 service함수에 몰려있다. 절차지향적 함수를 만들고 트랜잭션으로 묶은 것이다. 트랜잭션이 걸려있는 스크립트를 실행하는 것일 뿐이다.

public class MemberSErcie{
  private final MemberRepository memberRepository;
  
  @Transaction
  public Member creaete{
    // 검증하기
    // 연산하기
    // 저장하기
    // 등등..
  }
}

 

그렇다면 아래와 같이 생각해보면어떨까? 일반적인 구조이지만 레이어가 더욱 명확해졌다. 비즈니스 로직이 도메인으로 분리되면 서비스가 보다 가벼워졌다. 비즈니스 로직이 서비스 레이어에 작성되지 않고 도메인들이 협력할 수 있는 공간 정도로 바뀌었다.

 

 

 

서비스와 도메인 레이어에 대해 중요하게 다루었다. 서비스를 트랜잭션 스크립트로 사용하면 안된다. 도메인이 잘 협력할 수 있는 공간으로 사용해야한다. 그리고 비즈니스 로직은 도메인 영역에 작성 되어야한다.