[DISCUSSION] BoardQueryAdapter의 findById 및 findAll 메서드에서 REMOVED 상태인 게시글 처리 논의

[wowddok99]

이슈 개요

BoardQueryAdapter(RDB Adapter)

// 기존 코드
@Override
    public Optional<Board> findById(Long id) {
        return boardEntityMapper.toOptionalDomain(
                getQuerydsl().createQuery()
                        .select(boardEntity)
                        .from(boardEntity)
                        .where(
                                boardEntity.id.eq(id),
                                boardEntity.status.ne(BoardStatus.REMOVED)
                        ).fetchOne()
        );
    }

현재 BoardQueryAdapter의 findById와 findAll 메서드는 상태가 REMOVED인 게시글을 조회하지 않도록 설계되어 있습니다. 2025년 1월 15일에 진행된 라이브 코드 리뷰에서 이 문제에 대한 논의가 필요하다는 의견이 있어, 이를 이슈로 등록하게 되었습니다.
아래의 관점 외에도 추가적으로 제시할 의견이 있다면 함께 논의해보면 좋겠습니다.

• 관점 A : 메서드 명을 그대로 사용하고 REMOVED 필터를 사용하지 않습니다.
  • REMOVED 상태인 게시물을 DB에서 포함하여 조회하면, 사용자에게 해당 게시물이 삭제되었다는 정보를 제공할 수 있습니다.
• 관점 B : 메서드 명에 REMOVED 상태를 제외한다고 명시하고 REMOVED 필터를 사용합니다.
  • REMOVED 상태인 게시물을 DB에서 제외하고 조회하면, 사용자에게 해당 게시물이 삭제되었다는 정보를 제공이 어렵습니다.
    • 게시물이 실제로 존재하지 않는 경우와 존재했던 게시물이 삭제된 경우는 명확한 차이가 있습니다.
    • 사용자의 실수나 악의적인 게시글 ID 입력에 대한 적절한 처리가 필요합니다. 이러한 처리는 사실상 비효율적이며 적합하지 않다고 생각합니다.

부연 설명

관점 A : 메서드 명을 그대로 사용하고 REMOVED 필터를 사용하지 않습니다.

    @Override
    public Optional<Board> findById(Long id) {
        return boardEntityMapper.toOptionalDomain(
                getQuerydsl().createQuery()
                        .select(boardEntity)
                        .from(boardEntity)
                        .where(
                                boardEntity.id.eq(id)
                        ).fetchOne()
        );
    }

관점 B : 메서드 명에 REMOVED 상태를 제외한다고 명시하고 REMOVED 필터를 사용합니다.

    @Override
    public Optional<Board> findByIdExcludingRemoved (Long id) {
        return boardEntityMapper.toOptionalDomain(
                getQuerydsl().createQuery()
                        .select(boardEntity)
                        .from(boardEntity)
                        .where(
                                boardEntity.id.eq(id),
                                boardEntity.status.ne(BoardStatus.REMOVED)
                        ).fetchOne()
        );
    }

[taewookimm]

@wowddok99 님!
신중한 고민이 담긴 논의 제안 감사드립니다!
제안 해주신 관점 A, 관점 B 둘 다 좋은 방안인것같습니다. 그리고 추가적인 제 생각은 이렇습니다!

추가 방안

adapter는 시키는 일(어플리케이션 계층에서 필요로 하는 일)만 해야 한다는 의미를 봤을 때 status 값을 adapter에서 고정적으로 넣는 것은 다소 처리가 아쉬울 수 있습니다.

그래서 status 값 또한 넘겨받아 처리를 하는 방안을 제안 드립니다. 다만, REMOVED의 값으로 조회가 많이 일어날 것인가? 또한 REMOVED의 값 조회가 일어난다 하더라도 같은 함수를 사용할 것인가?에 대해 고민이 필요해 보입니다.

만약 게시판 서비스 내 협의점으로 REMOVED 조회를 막을 것이라면 조회 전 status의 값이 REMOVED로 들어왔을 때 예외 처리를 해주는 것이 좋다고 생각합니다. 또한, 함수 명도 REMOVED 제외한 조회라는 명칭으로 변경되면 좋을 것 같습니다.

그렇지만 저는 REMOVED를 제외하는 것보단 모든 status를 허용하고 status 값에 따른 조회, 핸들링은 어플리케이션 계층에서 하는 것이 좋다고 생각됩니다.

    @Override
    public Optional<Board> findById(Long id, BoardStatus status) {
        return boardEntityMapper.toOptionalDomain(
                getQuerydsl().createQuery()
                        .select(boardEntity)
                        .from(boardEntity)
                        .where(
                                boardEntity.id.eq(id),
                                boardEntity.status.eq(status)
                        ).fetchOne()
        );
    }

[shin-jingyu]

@wowddok99 @taewookimm 좋은 의견 감사합니다!
클라이언트로부터 status를 전달받아 처리하는 방식이 adapter의 역할과 잘 맞는다고 생각합니다.
또한, @taewookimm 님이 제안해 주신 대로 status를 허용하고, 해당 status 값에 따라 조회 방식을 설정하는 접근이 적절하다고 생각합니다.

[merge-simpson]

@wowddok99 님, @taewookimm 님, @shin-jingyu 님!
모두 좋은 의견들을 남겨 주신 것 같습니다!

@wowddok99 님께서 생각하시는 여러 관점을 잘 정리해 주셔서
논의하기 수월한 것 같습니다!

주제가 명확해서 논의가 길게 연결되지 않아도 작업이 가능하셨던 것 같습니다.

💬 네이밍 방식 고려하기: 범용적으로 사용되는 Spring Data JPA 규칙 참고

반드시 Spring Data JPA의 네이밍 방식을 따르지 않아도 된다고 생각합니다.
왜냐하면 논의하신 부분이 Port의 스펙이므로 특정 기술에 종속되지 않기 때문입니다.

💊 그래도 범용적인 네이밍 관례와 유사하게 다룰 수 있도록, Spring Data JPA 네이밍 방식을 참고할 수 있다고 생각이 드네요.

• 어느 정도 Spring Data JPA 네이밍 방식을 참고할 수 있습니다.
• 물론 너무 길다고 생각하면 간소화하거나, 더 직관적인 표현을 선택하는 것은 우리 재량이라고 생각합니다.

Spring Data JPA 네이밍 규칙 참고

JPA Repository에서 조회 메서드 네이밍 규칙 예시

• find + 일부 키워드 또는 식별용 자유 문구 + By + 검색조건컬럼1 [+ In, Not, NotIn 등]
  • [+ AND 또는 OR + 검색조건컬럼2 [+ In, Not, NotIn 등]]

In, Not, NotIn 등 외에도 타입과 목적에 따라 다양한 연산자가 존재합니다.

Example Method Specs

// IdType은 ID의 타입으로 사용할 수 있는 예시입니다. 또 이하의 모든 메서드를 만들어야 하는 것은 아닙니다. (예시일 뿐입니다.)
Optional<BoardDetail> findBoardByIdAndStatus(IdType id, BoardStatus status);
Optional<BoardDetail> findBoardByIdAndStatusIn(IdType id, Collection<BoardStatus> status);
Optional<BoardDetail> findBoardByIdAndStatusNot(IdType id, BoardStatus status);
Optional<BoardDetail> findBoardByIdAndStatusNotIn(IdType id, Collection<BoardStatus> status);

[merge-simpson]

💊 A안 메서드 및 추가 메서드(Status 목록으로 받기: Set or Collection)

@taewookimm 님과 거의 같은 아이디어입니다.
거기에 status 목록을 파라미터로 받는 메서드를 추가로 제안하려고 합니다.

이전에 @wch-os 님의 PR #19 에서 status 목록을 Set 또는 추상화된 Collection으로 받는 것을 논의한 적이 있습니다.

• 관련 코멘트: Board Service 구현 및 단위 테스트 #19 (comment)

단, 어댑터에서 다룰 때는 일부 자료 구조가 순서의 영향을 받지 않으므로, 추가로 고려할 것이 있는지 살펴 봅니다.

순서 관련 캐싱 고려

• 순서의 영향을 받지 않는 자료 구조 사용 시, 일부 작업의 중간 소스에 대한 캐싱 등을 고려합니다.
  • Spring Data JPA 사용 시: Set 사용이 더 좋거나 같다고 기대할 수 있습니다. 이하 이유와 같습니다.
  • JDBC 베이스 기술들: PreparedStatement의 SQL 구조가 목록의 길이에만 영향을 받습니다. 따라서 중복 없이 검색 필터의 길이가 쉽게 유지되는 Set가 PreparedStatement 캐싱에 좋습니다.
• 일반적으로 중복을 제거한 Set의 최종 길이가 List보다 짧거나 같으므로, 최적화나 핸들링에 좋습니다.

예시 메서드 스펙

헥사고날 아키텍처 등 종속성을 감소시키는 구조를 지향하는 아키텍처는, 확장성과 유연성을 위해 더 추상적인 타입을 권장할 수 있습니다.
단, 구체적인 요건이 있을 때는 충분히 의미를 담은 타입을 고려하는 것이 좋습니다.

• Collection 파라미터 (확장성, 유연성)

  // 타입이 유연하기 때문에 확장 가능한 설계가 됩니다.
  Optional<BoardDetail> findByIdAndStatusIn(Long id, Colllection<BoardStatus> statuses);

• Set 파라미터 (추천: 제약이 명확하기 때문)

  // 타입이 어느 정도 유연하지만, Set 계열 자료 구조만 받도록 명확한 의미를 담습니다.
  Optional<BoardDetail> findByIdAndStatusIn(Long id, Set<BoardStatus> statuses);

개인적으로, 원하는 요건을 충분히 표현하는 Set 사용을 더 추천합니다.