게시판 도메인 모델

게시판의 첫 기능은 "회원이 제목과 본문을 가진 게시글을 작성한다"입니다. 짧은 문장이지만 코드로 옮기기 전에 애매한 부분을 먼저 없애야 합니다. 이 교재에서는 게시글 규칙을 다음과 같이 정합니다. 길이 숫자만 따로 저장하면 정작 화면에 보여 줄 본문을 잃으므로, 제목과 본문은 문자열 그대로 두고 길이는 그 문자열에서 계산합니다.

이 규칙을 컨트롤러의 if 문으로만 지키면, 배치 작업이나 테스트 픽스처처럼 다른 경로로 게시글을 만들 때 검사를 건너뛰게 됩니다. 그래서 문자열의 정규화와 길이, 작성일의 null 여부처럼 입력만 보고 판단할 수 있는 구조 규칙은 웹과 무관한 순수 Java 객체에 둡니다. 반면 "미래 날짜인가"는 오늘이 며칠인지라는 바깥의 기준이 있어야 판단할 수 있으므로, 애플리케이션의 사용 사례가 그 기준 날짜를 넘겨 검사를 호출해야 합니다. 객체를 만들었다는 것만으로 날짜 규칙까지 지켜지지는 않는다는 점이 이 글의 핵심입니다.

그림은 생성 값이 저장 상태가 되기까지 거쳐야 하는 세 단계를 보여 줍니다. 먼저 PostDraft 생성자가 구조를 검사하고, 다음으로 애플리케이션이 Clock에서 계산한 today를 validateDate(today)에 넘겨 날짜를 검사하며, 마지막으로 저장소가 양수 식별자를 붙여 Post로 바꿉니다. 마지막 저장소 단계는 다음 글에서 구현합니다.

생성 요청과 저장 모델

클라이언트가 보내는 값과 저장소가 붙이는 값은 생기는 시점이 다릅니다. 게시글을 만들어 달라는 요청에는 아직 id가 없으므로 그 입력은 PostDraft로 나타내고, 저장되어 양수 식별자가 붙은 상태는 Post로 나타냅니다.

package board.domain;

import java.time.LocalDate;

public record PostDraft(
        String authorId,
        String title,
        String content,
        LocalDate publishedOn
) {
    public PostDraft {
        authorId = requireText(authorId, "authorId", 50);
        title = requireText(title, "title", 80);
        content = requireText(content, "content", 720);
        if (publishedOn == null) {
            throw new IllegalArgumentException("publishedOn is required");
        }
    }

    public void validateDate(LocalDate today) {
        if (today == null) {
            throw new IllegalArgumentException("today is required");
        }
        if (publishedOn.isAfter(today)) {
            throw new IllegalArgumentException(
                    "publishedOn must not be in the future");
        }
    }

    private static String requireText(
            String value,
            String field,
            int maxUtf16Units
    ) {
        if (value == null || value.isBlank()) {
            throw new IllegalArgumentException(field + " is required");
        }
        var normalized = value.strip();
        if (normalized.length() > maxUtf16Units) {
            throw new IllegalArgumentException(
                    field + " must be at most " + maxUtf16Units
                            + " UTF-16 code units");
        }
        return normalized;
    }
}

레코드의 컴팩트 생성자(compact constructor) 안에서 컴포넌트 이름에 새 값을 대입하면, 그 값이 최종 필드에 저장됩니다. 그래서 PostDraft의 필드에는 앞뒤 공백을 지운 문자열이 들어갑니다. 이 생성자가 지키는 것은 세 문자열의 정규화와 길이, publishedOn의 null 여부까지입니다. 작성일이 미래인지는 시스템 날짜에 따라 달라지므로 생성자 안에서 LocalDate.now()를 부르지 않고, 사용 사례가 Clock으로 기준 날짜를 계산해 validateDate(today)를 호출하게 합니다. 사용 사례의 테스트도 이 날짜 검사가 저장소 호출보다 먼저 실행되는지 확인해야 합니다.

package board.domain;

import java.time.LocalDate;

public record Post(
        long id,
        String authorId,
        String title,
        String content,
        LocalDate publishedOn
) {
    public Post {
        if (id < 1) {
            throw new IllegalArgumentException("id must be positive");
        }
        var checked = new PostDraft(
                authorId, title, content, publishedOn);
        authorId = checked.authorId();
        title = checked.title();
        content = checked.content();
        publishedOn = checked.publishedOn();
    }

    public static Post saved(long id, PostDraft draft) {
        if (draft == null) {
            throw new IllegalArgumentException("draft is required");
        }
        return new Post(
                id,
                draft.authorId(),
                draft.title(),
                draft.content(),
                draft.publishedOn());
    }

    public int contentLength() {
        return content.length();
    }
}

Post.saved는 초안에 식별자를 붙이는 상태 전이를 이름으로 드러내는 정적 팩토리(factory) 메서드입니다. PostDraft에는 id 컴포넌트가 없으므로, 생성 입력을 거쳐서는 식별자를 넘길 수 없습니다. Post의 컴팩트 생성자는 안에서 PostDraft를 만들어 문자열과 작성일 규칙을 다시 씁니다. 그래서 Post의 생성자를 직접 호출하더라도 이 구조 규칙은 건너뛸 수 없습니다.

다만 레코드의 정식 생성자(canonical constructor)와 saved는 둘 다 public이므로 누가 호출하는지는 막지 못합니다. 누구든 임의의 양수 id를 넘길 수 있고, 미래 날짜 검사도 생성자가 자동으로 실행하지 않습니다. 따라서 식별자를 저장소가 붙였다는 것과 저장 전에 날짜를 검사했다는 것은 PostService가 날짜를 검사한 뒤 repository.save(draft)를 부르고, 저장소가 Post.saved를 호출하는 순서로 지켜야 합니다. 다음 글에서 애플리케이션 서비스와 저장소가 이 순서를 맡고 테스트로 확인합니다.

경계값 우선 테스트

평범한 본문 하나가 성공하는지만 보는 테스트로는 빈 본문, 721자 본문, 미래 날짜 같은 실패를 놓칩니다. 규칙의 한계 바로 안쪽과 바로 바깥쪽을 짝지어 검사합니다.

package board.domain;

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

import java.time.LocalDate;
import org.junit.jupiter.api.Test;

class PostDraftTest {
    private final LocalDate today = LocalDate.of(2026, 7, 13);

    @Test
    void 문자열을_정규화하고_유효한_게시글을_만든다() {
        var draft = new PostDraft(
                " member-1 ",
                " Spring MVC ",
                "Spring MVC 요청 흐름을 정리합니다.",
                today);

        draft.validateDate(today);

        assertThat(draft.authorId()).isEqualTo("member-1");
        assertThat(draft.title()).isEqualTo("Spring MVC");
    }

    @Test
    void 본문_길이는_1자부터_720자까지다() {
        assertThat(new PostDraft(
                "member-1", "Java", "a", today).content()).hasSize(1);
        assertThat(new PostDraft(
                "member-1", "Java", "a".repeat(720), today).content())
                .hasSize(720);

        assertThatThrownBy(() -> new PostDraft(
                "member-1", "Java", "", today))
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("content is required");
        assertThatThrownBy(() -> new PostDraft(
                "member-1", "Java", "a".repeat(721), today))
                .isInstanceOf(IllegalArgumentException.class);
    }

    @Test
    void 미래_작성일은_거부한다() {
        var tomorrow = today.plusDays(1);
        var draft = new PostDraft(
                "member-1", "HTTP", "HTTP 요청을 정리합니다.", tomorrow);

        assertThatThrownBy(() -> draft.validateDate(today))
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("publishedOn must not be in the future");
    }
}

./gradlew test --tests board.domain.PostDraftTest

세 테스트가 모두 통과하면 BUILD SUCCESSFUL로 끝납니다. 첫 테스트에서 " member-1 "과 " Spring MVC "는 생성자를 지나며 앞뒤 공백이 지워지고, 둘째 테스트에서 빈 문자열은 isBlank()에 걸려 content is required로, 721자 본문은 길이 검사에 걸려 거부됩니다. 셋째 테스트의 내일 날짜는 생성자를 통과하지만 validateDate(today)에서 거부됩니다.

도메인 시간 주입

다음 구현은 짧지만 테스트하기 어렵습니다. 아래 생성자는 LocalDate.now()를 인자 없이 부르므로, 기준 날짜를 시스템 시계와 JVM의 기본 시간대에서 직접 읽습니다. 호출하는 쪽이 그 기준을 정해 넘길 방법이 없다는 점을 보면서 읽습니다.

public PostDraft {
    if (publishedOn.isAfter(LocalDate.now())) {
        throw new IllegalArgumentException("future date");
    }
}

테스트가 자정을 지나는 순간 결과가 바뀔 수 있고, 사용자의 지역 시간과 서버의 지역 시간이 다르면 "오늘"이 언제인지도 분명하지 않습니다. 그래서 이번 단계에서는 서비스가 Clock에서 오늘 날짜를 계산해 validateDate에 넘깁니다. 나중에 회원마다 시간대를 지원하게 되면 그 결정은 서비스나 별도 정책 객체로 넓히면 됩니다. 시간을 밖에서 넣는다고 해서 인터페이스를 새로 만들 필요는 없습니다. java.time.Clock은 JDK가 제공하는, 바꿔 끼울 수 있는 시계이므로 그대로 쓰면 됩니다.

var clock = Clock.fixed(
        Instant.parse("2026-07-13T00:00:00Z"),
        ZoneOffset.UTC);
var today = LocalDate.now(clock);

draft.validateDate(today);

Clock.fixed는 테스트가 기준 시각과 시간대를 정하게 해 주므로, LocalDate.now(clock)은 언제 실행해도 2026년 7월 13일을 돌려줍니다. 실제 애플리케이션에서도 사용 사례가 주입받은 Clock으로 today를 계산하고 같은 validateDate(today)를 호출합니다.

그림의 위쪽은 이 시간 전달 경로를, 표는 PostDraftTest가 실제로 확인한 규칙과 아직 확인하지 않은 규칙을 나누어 보여 줍니다. 본문 길이는 1과 720의 통과, 빈 문자열과 721의 거부까지 모두 확인했고, 작성일은 오늘의 통과와 내일의 거부를 확인했습니다. 반면 회원 식별자의 50자와 51자, 제목의 80자와 81자는 아직 확인하지 않았고, content의 정규화도 직접 검사하지 않았습니다. publishedOn이나 today가 null인 경우와 과거 날짜도 따로 테스트하지 않았습니다. 코드에 규칙을 적었다는 것과 테스트로 확인했다는 것은 다르므로, 이런 빈칸은 연습 문제와 이후 테스트로 채웁니다.

도메인 예외와 HTTP 분리

IllegalArgumentException을 그대로 API 사용자에게 보여 주는 것이 최종 설계는 아닙니다. 그렇다고 지금 ProblemDetail이나 상태 코드, JSON 오류 형식을 도메인에 넣으면 순수한 업무 규칙이 HTTP 기술에 의존하게 됩니다. 그래서 일을 세 층으로 나눕니다. 도메인은 구조 규칙과 넘겨받은 기준 날짜를 어긴 입력을 예외로 거부하고, 애플리케이션 서비스는 날짜 검사를 호출하고, 중복 게시글이나 없는 게시글처럼 사용 사례에서 생긴 실패를 전용 예외로 알립니다. 마지막으로 웹 계층의 컨트롤러 어드바이스(controller advice)가 예외를 HTTP 400이나 404 응답으로 바꿉니다. 세 번째 층은 게시판 웹 등록·조회에서 실제 컨트롤러와 함께 만들며, 지금은 도메인 테스트가 Spring 컨텍스트 없이 실행된다는 점만 확인하면 됩니다.

값 객체 도입 시점

authorId와 title을 지금 바로 별도 레코드로 만들 수도 있습니다. 하지만 타입을 하나 추가할 때는 그 덕분에 검증의 중복, 단위의 혼동, 인자 순서를 잘못 넘기는 실수 같은 실제 문제가 줄어드는지를 먼저 봐야 합니다. 지금 본문 길이는 content.length() 하나로 계산할 수 있습니다. 앞으로 입력 제한과 요약 표시에서 같은 계산이 되풀이된다면 PostContent 같은 값 객체가 정규화와 길이 정책을 함께 맡게 할 수 있습니다. 반면 title이 화면에 표시하는 문자열로만 쓰이는 동안에는 TitleName 같은 타입이 파일만 늘릴 수도 있습니다. 이 교재는 실제로 바꿀 이유가 생겼을 때 리팩터링하고, 테스트로 동작이 그대로인지 확인하며 옮깁니다.

저장소 규칙 확인

이제 저장소가 받을 값은 PostDraft, 저장한 뒤 돌려줄 값은 Post로 정해졌습니다. 저장소에 넘기는 초안은 생성자의 구조 규칙과 사용 사례의 날짜 검사를 모두 통과했고 아직 식별자가 없는 값이며, 저장된 상태는 양수 식별자와 초안의 값을 합친 Post입니다. 유효하지 않은 초안은 저장소를 호출하기 전에 거부되어야 합니다. 다음 글에서는 이 순서를 저장소와 애플리케이션 서비스의 테스트로 확인합니다. public인 Post 생성자는 PostDraft의 구조 규칙을 다시 쓰지만, 저장소가 식별자를 붙였다는 것이나 사용 사례가 날짜를 검사했다는 것까지 알려 주지는 않기 때문입니다.

정리

• 게시글을 만드는 입력은 식별자가 없는 PostDraft로, 저장된 상태는 양수 식별자가 있는 Post로 나눕니다.
• 입력만 보고 판단할 수 있는 정규화와 길이, null 규칙은 레코드의 컴팩트 생성자에 둡니다.
• 미래 날짜처럼 바깥의 기준이 필요한 규칙은 사용 사례가 Clock으로 계산한 today를 넘겨 호출하며, 생성자가 자동으로 지켜 주지 않습니다.
• 테스트는 규칙의 한계 바로 안쪽과 바깥쪽을 짝지어 확인하고, 코드에 적었지만 아직 확인하지 않은 규칙은 따로 남겨 둡니다.
• 도메인은 HTTP 기술을 모른 채 예외로 거부만 하고, 예외를 HTTP 응답으로 바꾸는 일은 웹 계층이 맡습니다.

연습 문제

1. 제목 길이 확인하기

PostDraftTest에 정확히 80자인 제목과 81자인 제목을 넣는 테스트를 추가하세요. 그다음 한글, 영문, 이모지에서 String.length()가 사용자가 보는 글자 수와 항상 같은지 조사하고, 길이 정책을 지금처럼 코드 단위로 둘지 사용자가 보는 글자 수로 바꿀지 이유와 함께 정하세요.

@Test
void 제목은_80자까지다() {
    var eighty = "a".repeat(80);
    var eightyOne = "a".repeat(81);

    assertThat(new PostDraft(
            "member-1", eighty, "본문", today).title()).hasSize(80);
    assertThatThrownBy(() -> new PostDraft(
            "member-1", eightyOne, "본문", today))
            .hasMessage("title must be at most 80 UTF-16 code units");
}

2. 생성자에서 날짜를 검사하지 않는 이유

누군가 "PostDraft 생성자에서 LocalDate.now()로 미래 날짜까지 검사하면 validateDate를 깜빡할 일이 없지 않나요?"라고 묻습니다. 이 방법의 문제를 두 가지 들어 설명하세요.

다음 글 저장소·서비스 테스트에서는 이 두 타입을 메모리에 저장하는 PostRepository와 게시글 등록 사용 사례를 만들고, 도메인 테스트는 그대로 둔 채 저장 규칙과 서비스의 호출 순서를 별도 테스트로 확인합니다.