[DISCUSSION] Domain BoardStatus와 Entity BoardStatus 관련 질문입니다.

[github-insu]

이슈 개요

Domain의 BoardStatus를 유지하고 Entity 쪽에서는 Domain쪽의 BoardStatus를 import해도 괜찮을까요?

부연 설명

• Application>Domain>Type>BoardStatus가 존재합니다.
• Adapter>Entity>Type>BoardStatus가 존재합니다.
• 위에서 두 BoardStatus가 같은 역할을 하고 있다고 생각됩니다. 그래서 Domain쪽의 BoardStatus를 유지한채로 Domain쪽의 BoardStatus를 import해서 사용하는 것은 어떤가 궁금합니다.

[sweetykr7]

Domain쪽의 BoardStatus를 공용으로 사용하는 것이 좋을 것 같습니다.
driven-query adapter쪽에서도 domain의 BoardStatus를 사용하였습니다.

[github-insu]

@sweetykr7님 코멘트 감사드립니다.
제가 인지하지 못하고 있는 BoardStatus 분리(Entity영역, Domain영역) 이점이라던가 나눠야하는 필연적인 이유가 있을 수도 있다는 생각이 들었습니다.
제 머리에서는 특별한 이유가 떠오르지 않아 discussion을 통해 이유가 있는지 찾아보고자 issue를 등록했습니다.
BoardStatus를 각각 나눌 이유를 찾지 못한다면 하나의 BoardStatus를 import하는 방식으로 코드 작성 진행하겠습니다. 결론이 나면 Query쪽 구현에도 빠르게 공유드리겠습니다.
의견 공유 감사드립니다.

[shin-jingyu]

Domain의 BoardStatus를 공용으로 활용하여 일관성 유지하는 게 유지 보수적으로 좋아 보입니다

[merge-simpson]

논의 보충

이 논의에 앞서 @github-insu 님 및 @silberbullet 님과 몇 가지 관점 설명을 주고 받았습니다.

논의의 도입에 일부 관점 설명이 필요했던 것 같습니다.
다들 이 설명을 추가로 살펴서 논의를 다시 진행해 주시면 감사하겠습니다.

@sweetykr7 님, @shin-jingyu 님도 다시 살펴보고, 새롭게 답변 부탁드리겠습니다.
물론 기존 관점을 유지하거나 보충하셔도 되고, 관점을 바꾸셔도 괜찮습니다.

백지 상태에서 논의를 새롭게 주고 받는 것도 좋지만, 기존에 파악되어 있는 여러 관점도 제시되어야 다양한 상황을 상상하면서 더 나은 관점이 있는지 고민할 수도 있기 때문에 관점을 미리 제시해 드리려고 합니다.

관점 제시의 목적은 생각의 제한이 아닌 확장입니다.

관점을 제시하면 정답처럼 생각되어 혹시나 생각을 제한할까 우려하는 관점도 물론 존재할 수 있습니다.

하지만 기존 관점을 백지화한 상태에서 표면적인 논제를 다루기에는 감이 잘 안 올 수 있기 때문에, 어떤 상황에 어떤 관점을 적용하는 사례가 있는지 각 사례를 본 후 공감하거나 반박하는 식으로 관점을 확장할 수 있다고 생각합니다.

---

논의의 실제 배경

DB에 저장되는 형태가 반드시 'Domain Model'에 사용되는 Status와 동일한 타입, 동일한 모습인지 살펴보아야 합니다.

다양한 관점

우리는 별도 채널에서 이루어진 기존 논의에서, 다음과 같은 기존 관점 목록을 도출할 수 있었습니다.

• A: 도메인 모델의 status를 그대로 사용할 수 있습니다.
  • A-1: 이때 name만 사용하여 데이터베이스에 VARCHAR로 저장할 수도 있습니다. (초기 개발용)
  • 또는 code 필드를 관리하여 데이터베이스에 정수로 저장할 수도 있습니다. (개선 시 권장되는 방식)
  • A-2: 만약 code를 결정할 때 비즈니스로직에서 특별한 의미를 담는다면, domain model의 status에서 코드를 결정하는 것이 좋을 수 있습니다.
  • A-3: 만약 code를 결정할 때, 특별한 논리적 의미 없이 데이터베이스에 저장하기 위한 순수한 용도라면, persistence 계층에서 코드를 결정하는 것이 좋을 수 있습니다.
• B: 기존 시스템과 통합 등 다양한 이유에서 DB에 저장되는 status의 실제 형태가 도메인 모델에 제시된 status와 다를 수 있으며, 이것을 처리하는 실제 계층이 persistence 어댑터 레이어이기 때문에 domain model의 status로부터 독립된 데이터를 사용할 수 있습니다.
• C: 양쪽에 enum을 만들 필요 없이, 애플리케이션 계층에만 enum status를 두고, persistence 계층에서는 DB에 저장할 때 실제 필요한 값으로 미리 매핑하여 사용할 수 있습니다.

참고할 수 있는 코드 사례 1: 도메인 모델에서 status의 code에 특별한 의미를 담아 코드를 결정합니다.

// 즉석에서 작성된 코드이므로 사소한 버그가 있을 수 있습니다.
public enum BoardStatus {
    PENDING(1, 0, false),
    ACTIVE(2, 0, true),
    SUSPENDED(3, 0, true),
    REMOVED(0, 0, false);

    private static final int CLASSIFYING_PARAMETER_MAX = (~0) >>> 4;
    private static final int PADDED_VALUE_MAX = 0b0111;

    private final int code;

    static {/* 이곳에서 중복되는 code 값이 있는지 체크 */}

    BoardStatus(int classifyingParameter, int paddedValue, boolean canRead) {
        // NOTE 다음 assertion condition 예시는 음수 범위를 제외한 코드 사용을 상정합니다.
        assert 0 <= classifyingParameter && classifyingParameter <= CLASSIFYING_PARAMETER_MAX
                : STR."Board status 분류용 파라미터는 0 이상 \{CLASSIFYING_PARAMETER_MAX} 이하여야 합니다.";
        assert 0 <= paddedValue && paddedValue <= PADDED_VALUE
                : STR."Board status paddedValue는 0~\{PADDED_VALUE} 범위여야 합니다.";

        /* X000_0000 0000_0000 0000_0000 0000_PPPR
         *  X: 사용하지 않는 비트
         *  0: 분류용 비트
         *  P: 패딩 된 비트 (동일 분류 내에서 구분용)
         *  R: 읽기 가능 여부를 표현하는 비트(1: readable, 0: unreadable)
         */
        this.code = (classifyingParameter << 4)
                | (paddedValue << 1)
                | (canRead ? 1 : 0);
    }
}

canRead 입력이 데이터베이스까지 반영되는 예시지만, 기획적 변경에 데이터베이스가 최소한의 영향만 받도록 하기 위해 canRead 필드를 별도로 관리하고, 동시에 비트에 표현하지 않을 수 있습니다. (이 방식을 권장하고 싶습니다.)

참고할 수 있는 코드 사례 2: MapStruct mapper 선언 시 default 메서드를 추가해서 enum <-> persistence 계층에서 관리하는 정수 코드 간 매핑을 합니다.

이 방식은 아직 테스트되지 않았습니다. 논리적인 맥락을 제시합니다.

@Mapper(componentModel = "spring")
public interface BoardMapper {
    // 이 메서드가 아래 toCode 메서드를 자동으로 사용합니다. (expected)
    BoardEntity toEntity(Board board);

    // 논리적 맥락을 표현했습니다. MapStruct 동작에 필요한 추가적인 코드가 있을 수도 있습니다. (확인이 필요합니다.)
    default Integer toCode(BoardStatus status) {
        return switch (status) {
            case ACTIVE -> ...;
            ...
            case null -> null;
        };

        // 또는 status에 코드 산출을 위한 기타 파라미터를 받아서(canRead 등) 정수 코드 값을 산출할 수도 있습니다.
        //  단, 역산출이 가능해야 역방향 매핑이 가능하므로, 계산 기반이 반드시 간편한 구조는 아닐 수 있습니다.
    }
}

---

요약

첨부된 사례 코드를 제외하고 보더라도, 앞서 언급된 다양한 관점에서 접근할 수 있었습니다.

위 다양한 관점의 설명에서 배경지식이 되는 전제적 관점은 다음과 같습니다.

• 초기에는 VARCHAR 등을 그대로 데이터베이스에 사용할 수 있습니다.
• 추후에는 정수 코드 값을 사용하여 데이터베이스에 저장하는 것이 일반적으로 권장되는 조치입니다.

이러한 배경지식을 공유하여, 다양한 전략을 보충하거나 반박하거나 추가해 볼 수 있을 것 같습니다.

[silberbullet]

@merge-simpson 님의 설명 감사드립니다. 👍

🫤 겉으로는 Application 계층의 BoardStatus를 가져오는 것은 헥사고날 아키텍처의 의미 수준에 적합해 보입니다.

하지만 그 경계 수준을 잘 짚어보아야 한다고 생각합니다. Application는 비즈니스 기획을 담당합니다. 또한, Adapter는 비즈니스 구현을 담당합니다. 단순 비즈니스 로직이란 명목은 사용자의 행위(Behavior) 자체라고 생각합니다. 그 행위에 대해 구체적인 BoardStauts는 추상적인 비즈니스 로직과 거리가 있다고 생각이 듭니다.

Application 인 Adpater 로 의존성 방향을 가지고 있지 않다면 하기의 내용이 모두 정답이라 생각합니다.

• Entity 용 Board Status enum을 따로 관라하기 (Adapter의 확장성과 자유도가 생김)
  • 하지만 @merge-simpson 님이 제시해준 것 처럼 MapStruct를 사용하고 있다면 굳이 필요 없어 보입니다.
• Domain의 Board Status를 인용하기 (전체적인 프로젝트의 유지보수성 향상)

[github-insu]

@merge-simpson님과 @silberbullet 님 코멘트 감사합니다.
저는 "구현"이라는 측면에서 중복된다는 생각에 discussion을 열었는데 생각치도 못하게 더 넓은 세상이 있었네요!
단순 코드 구현&유지 보수라는 관점뿐만 아니라 코드의 목적과 기능에 대해서 생각을 담은 구현이 필요 하다고 느껴졌습니다.
코멘트와 답변에 매우 감사드립니다. 몇 번이고 읽으면서 곱씹어보겠습니다.

다른 분들께서도 새로운 답변이 아니더라도 BoardStatus에 대한 질문에 어떤 생각이 드셨는지 공유해주시면 제게 큰 도움이 될 것 같습니다~

[sweetykr7]

다양한 관점에서 바라보면서 생각보다 놓친것들이 있구나를 느꼈습니다. 특히 @merge-simpson 님이 제시하신 B와 C부분에 대한 고민을 못하고 지나갔던것 같습니다.
다양한 관점과 코드예시까지 보여주셔서 감사합니다.