🍡 DDD 적용하기 - 3

이번 포스트는 실제 프로젝트에서 구현한 유저 정보 수정 요청에 대한 내용을 예시로 작성하였다.

---

1. 표현 영역 (Presentation)

역할

표현 영역은 사용자가 이용하는 화면과 그 흐름을 제공하고, 사용자의 요청을 응용 서비스에 전달하고 결과를 돌려 받아 다시 사용자에게 제공한다. 사용자의 요청를 잘 변환하여 응용 서비스의 메소드 파라미터로 전달해주는 역할을 한다.

해당 영역에서 서비스의 주요 비즈니스 로직이 노출되어서는 안된다. 계층 간 의존성이 너무 높아지기도 하고, 데이터 변경이 트랜잭션 단위로 이루어져야 하기 때문이다.

예시

아래 예시는 유저 정보 수정 요청에 대한 표현 영역 코드이다.

    @Operation(summary = "유저 정보 수정")
    @CachePut(value = USER_KEY, key = "#user.getId()", cacheManager = "cacheManager")
    @PatchMapping(value = "", produces = "application/json; charset=utf-8")
    @ResponseBody
    public CommonResponse editUserAccount(@AuthenticationPrincipal User user,
            @Valid @RequestBody UserRequest.EditAccountRequest request) {

        var userCommand = userRequestMapper.of(request);
        var userResult = userFacade.editUserAccount(user, userCommand);
        var response = userResponseMapper.of(userResult);

        return CommonResponse.onSuccess(response);
    }

직관적인 네이밍으로 Facade에서 무엇을 하는지 파악할 수는 있지만, 정확한 비즈니스 로직과 도메인 로직의 흐름이 노출되지 않았음을 확인할 수 있다.

해당 메소드에서는 @AuthentcationPrincipal을 통해 이미 JWT 토큰 복호화로 얻은 유저 정보와 수정하고자 하는 정보 request가 RequestBody로 함께 요청된다. Mapper 활용을 통해 Request와 Response가 각 계층 간 그리고 리스폰스로 반환 될 때 각기 다른 객체에 담겨 전달된다.

---

2. 응용 영역 (Application)

역할

응용 영역의 경우 사용자로부터 들어온 요청을 Controller가 해석하여 데이터를 알맞게 넘겨주면 그에 따라 수행할 작업을 정의하고 도메인 서비스를 호출한다.

응용 서비스의 주된 역할은 도메인 객체 기반의 로직의 흐름을 제어하는 것이다. 예시로 도메인 서비스 호출 이후 별개로 알림을 보내야 하는 경우에도 알림 서비스를 해당 계층에서 호출한다.

예시

아래 예시는 유저 정보 수정 요청에 대한 응용 영역 코드이다.

    public UserInfo.Main editUserAccount(User user, UserCommand.EditAccountRequest request) {
        return userService.editUserAccount(user, request);
    }

해당 레이어는 아주 얇은 레이어로 간단하게 서비스를 호출하고 그 값을 반환해준다.

---

3. 도메인 영역 (Domain)

역할

도메인 영역에서 이전 영역들에서 이루어지지 않는 중요한 비즈니스 로직들이 이루어진다.

Entity가 정의되어 있는 영역이며, Infrastructure 영역에서 구현되는 기능을 활용하기 위한 읽기, 쓰기 역할의 인터페이스가 정의되어 있다. 도메인 객체를 가져온 뒤, 기능에 맞게 사용하여 로직을 처리하고 결과를 다시 응용 영역에 넘겨 준다.

도메인 로직을 응용 서비스에서 행하는 경우에는 코드의 응집성도 낮아지고 중복 코드가 발생할 수 있어 기피해야 한다.

예시

	private final UserStore userStore;

    @Override
    @Transactional
    public UserInfo.Main editUserAccount(User user, UserCommand.EditAccountRequest request) {
        user.editAccount(request);
        userStore.store(user);
        return userInfoMapper.of(user);
    }

유저 검증은 JWT 토큰으로 유저를 인증하는 과정에서 진행되어 생략하였다.

Store라는 인터페이스를 활용하여 infrastructure 영역에서 변경된 user 객체를 저장해준다. 이후 Mapper를 통해 해당 엔티티를 DTO로 감싸 응용 영역으로 전달한다.

도메인 객체의 값을 변경하는 로직은 editAccount에서 행해지며 다음과 같다.

    public void editAccount(UserCommand.EditAccountRequest request) {
        updateName(request.getName());
        updatePlan(request.getPlan());
    }

    public void updateName(String name) {
        if (name != null) {
            this.name = name;
        }
    }

    public void updatePlan(String plan) {
        if (plan != null) {
            this.plan = PlanStatus.valueOf(plan);
        }
    }

---

4. 인프라스트럭쳐 영역 (Infrastructure)

역할

가장 low level 구현체로 기술적 기능들을 제공한다. DIP 개념을 활용하여 domain 계층에서 추상화 된 인터페이스를 구현한다.

Repository가 위치하며, 그 외에도 도메인 계층에서 정의 된 인터페이스를 구현하여 Repository를 호출한다. 예시에서는 UserStore가 인터페이스에 해당하며, 인프라스트럭처 영역에서 UserStoreImpl이라는 구현체를 작성해주었다.

예시

    private final UserRepository userRepository;

    @Override
    public User store(User user) {
        return userRepository.save(user);
    }

---

트랜잭션

DB의 ACID 성질 보장을 위해 @Transactional 어노테이션으로 간편하게 트랜잭션 처리하였다.

DTO

사용자로부터 요청 받고 반환 되는 Request와 Response는 Presentation Layer에 자리했다. 그 외에 Domain 영역에서 엔티티를 다른 계층에 넘길 때 감싸기 위해 사용하는 DTO는 전부 Domain 영역에 정의되었다.

데이터 검증

표현 영역에서는 단순히 값의 존재 여부를 판단했다면, 도메인 서비스는 값이 해당 도메인에 맞는 유효한 값인지 검증하는 과정이 필요하다. 아래와 같이 생년월일 날짜 스트링이 유효한 날짜 값인지 검증하거나, 추가로 100살 미만인지 등을 검증하기도 하였다.

	SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMMdd");
    dateFormat.setLenient(false);
    try {
        dateFormat.parse(userTypeRequest.getBirthday());
    } catch (ParseException e) {
        throw new BadRequestException(ErrorCode.INVALID_BIRTHDAY.getErrorCode());
    }