더 명시적인 Soft Delete 정책을 위해 저희 이렇게 코딩을 해보면 어떨까요?

[silberbullet]

안녕하세요! 금일 2025.2.12(수) 회의에서 구두로 말씀했던 Soft Delete가 뭔가 흐지부지 끝나서 글을 올립니다.

현재 저희 Board가 Hard Delete(delete)랑 Soft Delete 사이에서 애매한 구간에 있다고 생각합니다. 그래서 하기와 같이 저의 생각을 공유합니다.

❗ Board 도메인에서는 Hard Delete를 명시하지 않기

Hard Delete(delete)는 DB에서 데이터 삭제를 의미합니다.
Soft Delete는 DB에 데이터를 보존하면서 상태 값을 활용하여 삭제를 명시합니다.

백엔드 팀은 Board 도메인에서는 Soft Delete로 정해졌습니다. 이는 하나의 정책이라고 생각합니다. 이 정책을 명시하는 역할은 Application Layer 계층에 담당이라고 생각합니다.

그렇기에 interface 하기와 같이 수정이 이루어지면 좋겠습니다.

• BoardCommandPort 수정 전

public interface BoardCommandPort {
     ...
    // Hard Delete 
    void delete(Long id);
}

• BoardCommandPort 수정 후

public interface BoardCommandPort {
     ...
    // 더 명확한 Soft Delete 명시 
    void softDelete(Long id, BoardStatus status);
}

또한, service는 다음과 같이 수정이 됐으면 좋겠습니다.

• BoardCommandService 수정 전

public class BoardCommandService implements BoardCreateUseCase, BoardUpdateUseCase, BoardDeleteUseCase {
 ...
   public void deleteBoard(Long id) {
        Board board = boardCommandPort.findById(id).orElseThrow(
                () -> new IllegalArgumentException("게시글을 찾을 수 없습니다."));

        board.softDelete();

        boardCommandPort.delete(id);
    }
}

• BoardCommandService 수정 후

public class BoardCommandService implements BoardCreateUseCase, BoardUpdateUseCase, BoardDeleteUseCase {
   ...
   public void deleteBoard(Long id) {
        boardCommandPort.softDelete(id, BoardStatus.REMOVED);
        
        // board가 Hard Delete가 됐는지 확인
        var board = boardCommandPort.findById(id).orElseThrow(
             // 에러 반환
        )
       // 방어 로직 추가 (선택)
       if(!BoardStatus.REMOVED.equals(board.getStatus())){
            // throws BoardCommandException
       }
    }
}

위와 같다면 Adapter도 Application Layer의 정책에 맞게 코딩을 하지 않을까 합니다!

더 나은 방안이 있다면 공유해주시면 감사합니다!

[merge-simpson]

안녕하세요, @silberbullet 님!
명시적인 메서드 명명은 아주 중요한 언급이라고 생각합니다.

이번에 강조하신 대로, 이 논의가 지난 몇 차례 동안 강조된 내용이었음에도
많은 논의 사이에서 특별히 눈에 띄지 못했을 수 있습니다.

이 내용을 리마인드 할 수 있도록 논의로 정리해 주심에 감사드립니다. 👍 🚀

---

👁️‍🗨️ 기존 논의의 리마인드

사람들이 놓쳤을 수 있는 일부 논의와 리뷰에서 다음과 같이 결정했으며, 잠정적으로 그런 작업이 발생한 것 같습니다.

• Soft delete를 실현하기 위한 메서드를 추가합니다.
• Hard Delete용 메서드는 남겨 둘지, 삭제할지 결정합니다.
  *남겨 두듯이 작업이 진행이 됐습니다.

💡 개선하고 싶은 아이디어

❗ 실제 조회 대신 Assertion에 위임

제안해 주신 코드의 일부:

// board가 Hard Delete가 됐는지 확인
var board = boardCommandPort.findById(id)
        .orElseThrow(/* returns exception */)

제가 생각하는 방향으로 개선할 때 코드:

assert boardCommandPort.existsById(id) : "데이터베이스에서 실제로 삭제되어선 안 됩니다.";

개선으로 생각하는 이유

프로덕션 코드에서 매번 '조회' 로직이 실제로 수행되지 않고도 안전성을 제공받을 수 있습니다.

• assert 키워드는 테스트 코드 등 -ea 옵션(enable assertion)이 실행 옵션에 포함되었을 때 동작합니다.
• 테스트 코드에서 "하드 딜리트가 되지는 않았는지 테스트" 항목이 누락되더라도, 프로덕션 코드의 assert에서 필터됩니다.

🎨 열거 상수의 비교에 equals 대신 == 연산자 사용

열거상수는 유일성을 보장받는 객체입니다. 어느 싱글톤 객체보다도 그 유일성에 대해서는 뚜렷하게 보장받으며, 런타임에 새로운 열거 상수를 생성할 수 없어 열거상수의 비교는 일반적으로 ==, != 연산자로 충분합니다.

실제로 우리가 직접 오버라이딩하지 않은 equals 메서드를 호출해도, 내부에서 == 연산을 수행합니다. 열거 상수의 equals 메서드의 오버라이딩은, 서로 다른 열거 상수 간에도 동일하게 취급해야 하는 가능성이 있을 때는 할지도 모릅니다.

따라서 가독성을 생각해 == 연산을 제안드립니다.

assert boardJpaRepository.findById(board.getId())
        .filter((existingBoard) -> existingBoard.getStatus() == BoardStatus.REMOVED)
        .isPresent()
        : "소프트 딜리트 된 보드는 status가 `REMOVED`여야 합니다.";

💊 또는 테스트 코드에서 수행

위 로직을 초기 개발 시 프로덕션 코드에서 방어적으로 추가할 수 있습니다. (테스트 코드를 먼저 작성하지 않는다면.)
이후 위 로직이 프로덕션 코드로부터 독립할 수 있도록, 테스트 코드로 옮길 수 있습니다.

💊 메서드 스펙에 대한 선택지

소프트 딜리트를 위해 Repository Port 메서드의 스펙은 다음 선택지 중 하나일 수 있습니다.

• updateStatus(id, status)
  소프트 딜리트를 위한 REMOVED뿐 아니라, 다른 상태 업데이트에 대해서도 서비스 로직에서 선택하여 사용할 수 있습니다.
• softDeleteById(id)
  상태 업데이트 중 빈번하게 발생하고, 충분히 이해하기 쉽거나 각종 수단으로 명시적인 정책을 제시할 수 있다면 이 메서드 이름으로 충분할 수 있습니다.
  • 어댑터는 이 메서드를 구현할 때, 지정된 보드의 상태를 'REMOVED'로 바꾸어야 한다는 것을 정확히 인지할 수 있어야 합니다.

도메인의 정책을 관리하는 방식을 문서와 코드 중 무엇으로 할지 정하지 않았기 때문에, 지금은 이번처럼 유익한 논의로 주고 받을 수 있는 내용 같습니다.

[silberbullet]

좋은 아이디어 주셔서 감사합니다! 먼저 정책적으로 메소드 선택이 먼저 인 것 같네요!

[silberbullet]

다른 분들의 의견도 필요합니다. 명시적으로 메소드를 네이밍을 softDelete 할지 updateStatus를 할지 고민해보면 좋을 것 같네요!

소환술을 사용할게요 😄

@wowddok99 @jilpoom @shin-jingyu @taewookimm @github-insu @Ropung @sweetykr7

[merge-simpson]

메서드 네이밍과 함께 파라미터 스펙에 대해서도 논의가 필요합니다!
다른 분들도 함께 고려해 주시기 바랍니다.

[silberbullet]

차근차근 논의해보죠!

[github-insu]

✅ 공통 전제라 생각되는 점

• Soft Delete 기능은 BoardStatus를 REMOVED로 변경하는 작업을 의미합니다.
• Hard Delete 기능은 DB에서 데이터를 삭제하는 작업을 의미합니다.

💭 의견

• Port에 있는 Delete는 RdbAdapter에서 실질적으로 하는 작업과 관련있는 작업이라 생각됩니다.
  -> 따라서 Port 내의 Delete는 Hard Delete의 역할을 수행하는 메서드라 생각됩니다.

• Soft Delete는 Port의 Update 메서드를 이용해서 구현하는 것은 어떤가 하는 생각입니다.

[github-insu]

updateStatus가 application 단에서 사용하는 메서드 명을 의미하는 거였다면, 제가 잘못이해하고 있었습니다.
application의 메서드 명이라면 저는 softDelete라는 명시적인 의미를 표현하는게 조금 더 좋습니다~

[silberbullet]

일단 DynamicUpdate는 JPA 한정된 내용이라 번외일 것 같아요. application는 약간 정책(?)을 정하고 adapter한테 명령 내리는 입장으로 보고 있어요 저는 ㅎㅅㅎ

[silberbullet]

public interface BoardCommandPort {
     ...
    // 선택지 1 
    void softDelete(Long id);
    
    // 선택지 2 
    void updateStatus(Long id, BoardStatus status);
}

이런 느낌입니다. 인수님!

[github-insu]

RdbAdapter에서는 유저가 원하는 기능을 수행한다기보다 Application에서 정한 정책을 구현하는 하나의 작업 단위를 실행하는 관점으로 본다면, Application에서 Soft Delete를 실행할때 RdbAdapter의 updateStatus를 실행하는 느낌이 맞는거 같습니다.
BoardCommandPort에서 메서드명을 softDelete에 찬성했었는데 updateStaus로 변경하겠습니다.

BoardCommandPort 선택지 2번에 찬성합니다~

[merge-simpson]

저도 원칙이 @github-insu 님께서 말씀해 주신 대로, RDB Adapter가 DB 제어와 관련한 메서드 명칭을 갖는 것이 기본이라고 생각합니다.

RDB를 기준으로 설명하자면, '테이블'에서 데이터를 넣고 빼는 작업에 초점을 둘 수 있습니다.
RDB가 아니라면 테이블 대신 다른 개념이 위치할 수 있습니다.

• 테이블에 데이터를 삽입하다 (insert, create 등)
• 테이블에서 데이터를 수정하다 (update 등)
• 테이블에서 데이터를 삭제하다 (delete 등)
• 테이블에서 데이터를 조회하다 (find, select, search 등)

이렇게 데이터베이스 제어와 관련된 기능을 스펙화하고, 그것을 이용하는 것이 자연스럽습니다.

💊 추가적인 동작 명시

아마 논점이 되는 것 중 하나가, '소프트 딜리트'라는 동작을 데이터베이스 제어의 일환으로 완전히 편제시킬 것이냐 하는 것 같습니다.
그리고 이 특수한 동작에 대해서 다음과 같은 의도를 표현할 수도 있습니다.

"각 데이터베이스에서 이것을 상태 업데이트로 처리하든, 테이블이나 컬렉션을 옮기든 소프트 딜리트를 수행하라"

이러한 의도를 담은 메서드 스펙을 제공하여, 소프트 딜리트의 세부 구현을 어댑터에 위임할 수 있습니다.
소프트 딜리트의 세부 구현을 어댑터의 재량으로 넘길 수 있다는 점이 장점입니다.

이때는 인프라스트럭처의 데이터 관리 체계가 다르더라도,
어댑터를 교체하기 위해 애플리케이션 계층에 추가적인 작업이 필요하지 않을 수 있습니다.

[shin-jingyu]

명시적인 건 좋으나, softDelete란 명칭보단 updateStatus가 좋아보입니다. 레포지토리가 쪽에서 softDelete란 단어를 쓰면 마치 delete 메소드를 써야 할 것 같습니다!

[silberbullet]

adapter 쪽에서 오해를 불러 일으킬 수 있다 이 말씀이시죠?

[shin-jingyu]

네 맞습니다

[taewookimm]

안녕하세요, @silberbullet 님!
쉽게 놓칠 수 있는 부분인데 잘 정리해서 논의 올려주신 점 정말 감사드립니다 :)

제가 생각했을 땐 softDelete 명칭을 사용하는 것이 좋다고 생각합니다.

updateStatus 명칭을 사용할 수 있겠지만, 저희 서비스의 규모가 커졌을 때 어떤 부분은 Hard Delete를, 어떤 부분은 Soft Delete를 혼합해서 사용할 수 있다고 생각합니다.

updateStatus 명칭을 사용했을 때 위와 같은 경우가 생긴다면 다른 파트에 익숙지 않은 개발자가 볼 때 한 번에 알아보기 쉽지 않을 수 있고, 조금 복잡도가 올라간다면 휴먼 버그 또한 생길 수 있다고 생각합니다.

다만, 몇가지 고려해야할 점은 있는것 같습니다.

1. softDelete 명칭을 사용했을때, 다른 파트 또한 같은 경우가 생길텐데 불필요한 코드가 많이 생기지 않을까?
2. softDelete, HardDelete를 파트 별 혼합해서 사용할 경우, HardDelete를 사용하는 부분은 port에서 softDelete를 명시하지 않을 것인가? 통일성 및 나중을 위해 사용하지 않더라도 명시해 줄 것인가?
3. 게시판에서 상태만을 업데이트 시키는 기능이 필요한가?
   a. 만약 필요하다면 updateStatus로 게시판 일반 상태 업데이트, softDelete(상태 업데이트) 하나의 메서드로 사용하는 게 더 좋은가?

다른 분들께서도 의견 말씀해 주시면 더욱 좋을 것 같습니다!!

[silberbullet]

크으 논점이 뜨거워지네요. 의견이 많이 갈라지면 투표로 정해보는 것도 좋아보여요!
다만, 고려해야 하는 점을 들어가기 전에 아래 부분을 제가 이해를 못했습니다.

updateStatus 명칭을 사용했을 때 위와 같은 경우가 생긴다면 다른 파트에 익숙지 않은 개발자가 볼 때 한 번에 알아보기 쉽지 않을 수 있고, 조금 복잡도가 올라간다면 휴먼 버그 또한 생길 수 있다고 생각합니다.

어차피 port 쪽에서 아래와 같이 정의가 되어 있다면, Adapter 쪽에서 아 update id와 status를 통한 update 구나 하지 않을까 싶었습니다.

public interface BoardCommandPort {
     ...
    void updateStatus(Long id, BoardStatus status);
}

// Adapter는 Application이 하라는 대로 작업을 진행 할때
public class BoardCommandAdapter implements BoardCommandPort {
        private final BoardJpaRepository boardJpaRepository;
        private final BoardEntityMapper boardEntityMapper;
        ....
        @Override
        public void updateStatus(Long id, BoardStatus status) {
            // 아 메소드 보니 게시판 업데이트 구나! 상태 업데이트 쿼리를 짜야지!
            var board  = boardJpaRepository.findById(id))...;
            
            // status 세팅해주고..
            board.updateBuilder()
                 .status(status)
                 .build();
                 
            // 휴.. 하란대로 잘햇겟지?
            boardJpaRepository.save(board);
        }
}

이런 느낌이지 않을까 했었습니다. 혹시 간단한 예시 하나만 들어주시면 감사해요!

[taewookimm]

@silberbullet 님께서 하신 말씀이 맞습니다!
저는 해당 Apdater를 봤을 때 updateStatus만 있으면, 오잉 그럼 delete를 어디서 하는 거지? 그냥 status 업데이트할 때 SoftDelete도 같이 하는 건가?라는 의문이 생길 수 있다는 걸 말씀드린 거였습니다 :)

해당 문제는 사실 익숙지 않은 부분이어도 Service 로직을 먼저 확인해 보면 금방 나오는 문제이긴 하지만, softDelete라는 명칭 사용하면 위 혼동 없이 바로 직관적으로 알 수 있지 않을까 해서 한번 언급해 본 사항이었습니다!

[merge-simpson]

좋은 아이디어 제안 감사드립니다, @taewookimm 님!!! 🚀

저도 모두가 제안해 주신 여러 안에 많은 부분 동의하면서,
방금 말씀해 주신 안에 대해서 파생되는 고려 사항이 존재한다고 생각해서 덧붙이려고 합니다.

💊 Delete 정책의 도메인중심적 관리

포트 및 어댑터의 softDelete라는 메서드 명칭에서 장래에 생길 수 있는 혼란 중 하나는,
소프트 딜리트 시 항상 REMOVED라는 상태로만 업데이트 처리될 것인지라고 생각합니다.

예를 들어, 다음과 같은 상태 목록을 운영하는 특정 데이터가 발생했습니다.
이때 개발자는 사용자 상호작용에 따른 삭제 프로세스를 이해해야 합니다.

public enum SomethingStatus {
    // ...
    REMOVE_RESERVED,
    REMOVED
}

만약 기획상 사용자가 삭제 요청을 할 때, 이것을 '삭제 예약'으로 업데이트해야 한다면, 관련 제어를 어느 메서드가 담당할지 정해야 합니다.

💊 삭제 예약: 애플리케이션·도메인 계층에서 소프트 딜리트 시 '삭제 예약'으로 제어한다면

위 데이터는 소프트 딜리트 시 상태가 REMOVED가 아닌 REMOVE_RESERVED로 처리되어야 할 수 있습니다. (소프트 딜리트 메서드로 제어 시)
이처럼 삭제 시의 상태 정보를 어댑터가 제공받기 위해서 여러 수단을 사용할 수 있습니다.

• 코드 베이스: 소프트 딜리트용 상태를 메서드 등으로 제공합니다. (SomethingStatus getRemovedStatus(), 이때 static 여부 논의)
• 문서 베이스: 각 포트의 정책 문서를 작성하여, 어댑터가 구현할 스펙을 설명합니다.
• 또는 소규모 팀에서는 초기에 간략한 소통으로 할 수도 있습니다.

애플리케이션 및 도메인 계층에서 '소프트 딜리트 시 제공받고 싶은 상태 변화'를 제공하면, 어댑터 구현의 혼란이 감소하고 어댑터 교체를 원활하게 할 수 있습니다.

코드 베이스

코드 베이스로 제공 예시 1: static 제공 (유틸리티 클래스처럼)

// 정책을 제공하는 클래스류
public final class SomeClass {
    // ...

    public static SomethingStatus getRemovedStatus() {
        return REMOVED;
    }
}

코드 베이스로 제공 예시 2: 빈으로 제공

// 정책을 제공하는 컴포넌트류
@Component
public final class SomeClass {

    // ... (properties나 기타 빈 주입 등이 필요하다면 관련 코드 사용)

    public SomethingStatus getRemovedStatus() {
        // properties 사용이 
        return SomeProperties.removedStatus();
    }
}

💊 또는 소프트 딜리트 함수가 항상 REMOVED로 처리하고, 그 외에는 상태 업데이트 메서드를 사용할 수도 있습니다.

어쩌면 이것이 가장 원하는 타협안일 수 있습니다.
삭제 및 삭제 예약에 대한 제어권은 여전히 서비스 로직에 존재합니다.

단, softDelete라는 특수한 이름의 메서드가 항상 하나의 작업을 하는 것으로 약속해야 하며,
새 어댑터 구현이 이를 준수했는지 반드시 테스트해야 합니다.

• '삭제 예약' 시

  somethingCommandPort.updateStatus(id, SomethingStatus.REMOVE_RESERVED);

• '삭제' 시 (소프트 딜리트)

  somethingCommandPort.softDelete(id);

[silberbullet]

@taewookimm 님 예시로 들었을 때도 당연스럽게 있을 수 있는 휴먼 에러 이기도 하네요.

사실 상, RDB Adapter가 Service Layer를 파악하고 바라보는 건 헥사고날 아키텍처의 의미 수준에 맞는 것이죠.
저는 직장 내에 상사가 Service Layer, 사원이 RDB Adapter 이라고 생각합니다.

근데 사원이 휴먼 에러를 안 일으킨다는 보장은 없어 보입니다. 이런 메소드명은 어떨까요?

👀 updateForSoftDelete 혹은 updateSoftDelete

사원은 RDB Adapter를 구현할 시, 파라미터를 통해 update가 일어난다는 것과 softDelete란 단어를 통해 삭제 프로세스가 일어남을 알 수가 있을 것 같습니다.

또한 @merge-simpson 님이 말해주신 삭제와 삭제 예약은 Service 부분에서 프로세스 따라 상태 값을 넣을 수 있습니다.

// 로직 중 게시판 삭제가 필요할 때
somethingCommandPort.updateForSoftDelete(id, SomethingStatus.REMOVE);
// 로직 중 게시판 삭제 예약이 필요할 때
somethingCommandPort.updateForSoftDelete(id, SomethingStatus.REMOVE_RESERVED);

굳이 사원이 내가 받는 파라미터가 삭제인지 삭제 예약인 지는 알 필요 없이 구현하면 되는 것 같습니다.

어때요?? 납득이 되신다면 좋아요와 화살표 버튼 감사드립니다 :)

[sweetykr7]

단순히 remove만 생각하고 있었는데, reserved까지 고려할 상황까지 알려주셔서 감사합니다.

저도 updateState보다는 명시적으로 눈에 보일수 있는 메소드명이 더 나아보인다고 생각합니다.

말씀하신 updateSoftDelete도 괜찮은 대안 같습니다.

향후에 이렇게 delete에 대해서 다양한 status를 쓰게 되는경우 port를 분리하여 아래와 같이 쓰는 경우도 있는지 궁금합니다.

public interface BoardDeletePort { void markAsDeleted(Long id); // 예약 삭제 void softDeleteImmediately(Long id); // 즉시 삭제 }

[silberbullet]

저희 Delete Port는 따로 관리하지 않을 것 같습니다!

현재 CQRS 패턴에서 크게 두 가지인 Query, Command를 분리해서 관리해요. 향 후, DB도 쿼리 전용, 커맨드 전용으로 분리시키는 거구요. (대신 돈이 좀 필요하죠 ㅎㅎ)

Command는 일반적으로 저장, 삭제, 수정을 담당하는 영역입니다. 그렇기 때문에 삭제 방식이 많다고 해서 DeletePort를 따로 만들지 않고 CommandPort라는 전체적인 틀 안에서 관리가 되는거죠!

[sweetykr7]

아 그렇군요. 답변 감사드립니다!