통합 구조 제안

[ooMia]

DDD를 위한 프로젝트 구조

• 프로그래밍에서 정보를 정의하고, 데이터를 생성하고 검증하는 작업은 필수적이다. OOP에서는 추상화를 기반으로 클래스 간 상속 관계를 잘 정의해야 하고, 특히 DDD에서는 정형화된 포맷을 기반으로 확장하는 것이 유지/보수 편의성을 확보하는데 도움이 된다. 다음은 의식의 흐름대로 작성해보는 프로젝트 구조이다.
• 다음 3개의 인터페이스와 3개의 추상 클래스를 기반으로 도메인의 기본적인 틀을 구조화 할 수 있다.
  단일 도메인을 구성하는 기본 인터페이스의 상속 관계는 다음과 같다.

• 7.절에서는 손쉽게 도메인을 추가하는 과정을 소개한다.
  단일 도메인을 구성하는 기본 인터페이스와 클래스와 상속 관계는 다음과 같다.

자료구조

1. 스키마

• interface를 통해 자료형을 정의한다.
• 외부에서 참조 가능한 OutputSchema, 패키지 외부에서 전달되어 입력으로 사용되는 InputSchema, 또는 두 인터페이스를 모두 포괄하는 Schema로 추상화 가능하다.

public interface Schema {}

/**
 * 패키지 외부에서 참조 가능한 Schema
 */
public interface OutputSchema extends Schema {
}

/**
 * 패키지 외부에서 전달되어 입력으로 사용되는 Schema
 */
public interface InputSchema extends Schema {
}

도메인 적용

• entity 및 입출력 DTO에 대한 정의를 수행한다.
• 외부에서 entity 정의를 직접 참조하거나 간접적으로 유추할 수 있어선 안 된다. 외부에 노출되는 것은 DTO 이외에는 없다.

⚠️ package 간 참조는 입출력 DTO 정의를 기반으로 이루어져야 한다.

/**
 * 패키지 외부에서의 입력을 정의하는 Schema
 */
public interface ILottoInputDto extends InputSchema {
    List<Integer> numbers();
}

/**
 * 패키지 외부로 전달되는 출력을 정의하는 Schema
 */
public interface ILottoOutputDto extends OutputSchema {
    SortedSet<Integer> numbers();
}

[ooMia]

2. DTO

• 패키지 내부 entity 생성에 전달되는 입력 DTO를 ILottoInputDto에서 정의한다.
• VO로서 데이터를 저장하고, 패키지 외부로 노출하는 데이터를 ILottoOutputDto에서 정의한다.

/**
 * 패키지 외부에서의 입력을 정의하는 Schema
 */
public interface ILottoInputDto extends InputSchema {
    List<Integer> numbers();
}

/**
 * 패키지 외부로 전달되는 출력을 정의하는 Schema
 */
public interface ILottoOutputDto extends OutputSchema {
    SortedSet<Integer> numbers();
}

• 각 클래스는 필요에 따라 DTO 인터페이스를 구현하면 된다.

public record LottoOutputDto(
        SortedSet<Integer> numbers
) implements ILottoOutputDto {
    @Override
    public String toString() {
        return numbers.toString();
    }
}

⚠️ 외부에서 Lotto entity를 DTO의 형태로 생성하고 싶다면, 패키지 내 생성 역할을 수행할 때, ILottoInputDto 인터페이스가 포함된 구현체를 전달하면 된다. Lotto 패키지에서는 이외의 구현 사항은 관심사 밖이다. 가장 간단하게는 다음과 같이 작성할 수 있다.

public record LottoInputDto(
        List<Integer> numbers
) implements ILottoInputDto {
    @Override
    public String toString() {
        return numbers.toString();
    }
}

[ooMia]

3. Entity

• 확장성과 통일성을 위해 제네릭 인터페이스를 정의한다.

public abstract class Entity<IN extends InputSchema, OUT extends OutputSchema> {

    protected Entity(IN in, Validator<IN, OUT> validator) throws IllegalArgumentException {
        validator.validate(in);
        validator.validate(toDto());
    }

    protected abstract OUT toDto();
}

⚠️ base 패키지에 존재하는 3개의 추상 클래스는 모두 <IN extends InputSchema, OUT extends OutputSchema> 형태로 타입을 제공받아 정의되는 제네릭 클래스이다. 이러한 구조를 지니는 이점은 다음과 같다.

• 전달할 타입 파라미터를 통일했다. 이는 구현에 대한 개발 편의성을 증대한다.
• 내부적으

구현체

그 결과 Entity의 모습은 다음과 같다.

final class LottoEntity implements Entity<LottoOutputDto> {
    private final ILottoInputDto lotto;

    LottoEntity(List<Integer> numbers) {
        lotto = new Lotto(numbers);
    }

    @Override
    public LottoOutputDto toDto() {
        ...
    }

    private record Lotto(
            List<Integer> numbers
    ) implements ILottoInputDto {
        private Lotto {
            validate();
        }

        private void validate() throws IllegalArgumentException {
            ...
        }
    }
}

⚠️ 또는 상속을 고려한다면 다음과 같이 정의할 수도 있다.

class LottoEntity implements Entity<LottoOutputDto> {
    protected final ILottoInputDto lotto;
    ...

[ooMia]

4. Generator

• 모든 DTO는 entity.getDto()를 통해 생성되어야 한다. 그래야만 entity의 생명 주기에 따라 검증 과정을 거치며 생성된다. 그러나 entity를 package-private하게 관리한다면 패키지 외부에서는 이를 생성하거나 참조할 수 있는 권한이 없다.
• 이런 경우, 중개자를 사용할 수 있다. Generator는 패키지 내부와 외부를 중개하는 인터페이스로서, 액터는 해당 인터페이스를 통해 간접적으로 entity에 접근할 수 있다.

정의

• 이전과 마찬가지로 제네릭 인터페이스부터 정의한다.
• 내부에서 명시적인 예외를 catch하고 IllegalArgumentException로 던지도록 구성한다.
  이렇게 던져진 예외는 최초 호출 시점에 최종적으로 try-catch로 처리된다.
• 최초 호출의 개념은 격리된 패키지에 대한 각각의 진입 시점을 의미한다.

public interface Generator<IN extends Schema, OUT extends Schema> {
    OUT generate(IN in) throws IllegalArgumentException;
}

그 결과 Generator 구현체의 모습은 다음과 같다.

public class LottoGenerator implements Generator<ILottoInputDto, LottoOutputDto> {
    @Override
    public LottoOutputDto generate(ILottoInputDto iLottoInput) throws IllegalArgumentException {
        LottoEntity entity = new LottoEntity(iLottoInput.numbers());
        return entity.toDto();
    }
}

⚠️ entity 공개

• entity가 생성의 책임을 스스로 갖는 경우는 간단하다.
  클래스 자체가 public으로 공개되어 있어야 하고, validate()를 통한 내부 검증 과정이 필요하다.
• 내부에서 명시적인 예외를 catch하면 IllegalArgumentException로 던지도록 구성한다. 이렇게 던져진 예외는 최초 기능 호출 시점에 최종적으로 try-catch로 처리된다.
• public entity를 사용하면 빠르게 프로그램을 작성할 수 있다. 하지만 모범 사례로는 적절하지 않다.

public final class LottoEntity implements ILotto, Entity<LottoOutputDto> {
    private final ILotto lotto;

    LottoEntity(List<Integer> numbers) {
        validate(numbers);
        lotto = new Lotto(numbers);
    }

    private void validate(List<Integer> numbers) throws IllegalArgumentException {
        ...
    }

    @Override
    public SortedSet<Integer> numbers() {
        return lotto.numbers();
    }
    ...
}

⚠️ 또는 LottoEntity 내부 레코드에 검증 책임을 위임할 수도 있다.

public final class LottoEntity implements Entity<ILotto, LottoDto> {
    private final ILotto lotto;

    LottoEntity(List<Integer> numbers) {
        lotto = new Lotto(numbers);
    }
    ...
    private record Lotto(
            List<Integer> numbers
    ) implements ILottoInputDto {
        private Lotto {
            validate();
        }

        private void validate() throws IllegalArgumentException {
            ...
        }
    }
}

[ooMia]

5. Validator - 검증의 복잡도와 가변성

• 만약 검증 로직이 복잡하거나 차후 변경될 여지가 있다면 어떨까? 변경 가능한 지점을 식별하고 이를 인터페이스로 정의하거나 클래스로 분리하는 것이 OOP의 핵심이다.
• 따라서, Validator 클래스로 분리할 수 있다. 이 때, 제네릭 인터페이스를 사용하여 구조의 통일성을 강제할 수 있다.

public interface Validator<T extends Schema> {
    void validate(T t) throws IllegalArgumentException;
}

⚠️ 제네릭 추상 클래스도 사용할 수 있다.
그러나 Java에서는 다중 상속이 불가능하므로, 특별한 이유가 없다면 인터페이스를 활용하는 것이 낫다.

public abstract class Validator<T extends Schema> {
    abstract void validate(T t) throws IllegalArgumentException;
}

구현체의 모습은 다음과 같다.

• 검증은 패키지 내부에서 이루어져야 하므로, package-private로 선언한다. 모든 검증은 데이터가 패키지 밖에서 참조되기 전에 이루어져야 하기 때문이다. 만약 검증이 밖에서 이루어진다면, 이후 액터는 DTO의 데이터 무결성을 신뢰할 수 없고, 다른 도메인에 대한 검증 방법까지 숙지해야 한다.
• 검증 로직이 복잡하다면 구현체는 별도의 파일에 정의되는 것이 바람직하다. 단순히 파일의 길이뿐만 아니라 클래스 간 관계 설정 결과가 더 깔끔하기 때문이다.
• 본 구현체는 ILottoInputDto를 검증한다. 런타임에서는 전달되는 입력만 검증한다. 외부에 전달하는 ILottoOutputDto에 대해서는 별도의 검증 과정을 거치지 않는다. 대신, 유닛 테스트로 확인한다.

class LottoValidator implements Validator<ILottoInputDto> {

    @Override
    public void validate(ILottoInputDto input) throws IllegalArgumentException {

    }
}

[ooMia]

새로운 관심사의 추가

6. LottoBonus와 LottoPrize

이를 고려한 model 내 패키지 정리를 진행하면 다음과 같다

역할	접근 제어 수준
entity	package-private
validator	package-private
generator	public
DTO	public

• lotto
  • model
    • lotto
      • ILotto.java
      • ILottoInputDto.java
      • ILottoOutputDto.java
      • LottoEntity.java
      • LottoGenerator.java
      • LottoValidator.java
      • LottoOutputDto.java
      • bonus
        • ILottoBonus.java
        • ILottoBonusInputDto.java
        • ILottoBonusOutputDto.java
        • LottoBonusEntity.java
        • LottoBonusGenerator.java
        • LottoBonusValidator.java
        • LottoBonusOutputDto.java
      • prize
        • ILottoPrize.java
        • ILottoPrizeInputDto.java
        • ILottoPrizeOutputDto.java
        • LottoPrizeEntity.java
        • LottoPrizeGenerator.java
        • LottoPrizeValidator.java
        • LottoPrizeOutputDto.java

[ooMia]

7. 도메인 추가

클래스 복사

파일에서 바꾸기

경로 선택

대소문자 일치 -> 모두 바꾸기

• 각 파일명을 클래스명에 맞게 변경
• 구현체 수정