[Spring] ConfigurationProperties POJOs 설계

File Storage -> Kafka 로 중복 없이 레코드를 전송하는 라이브러리를 만들고 있다.

다음과 같이 Configuration yaml 을 디자인했다고 해보자.

storage:
  type: local, s3, blob # here is deciding which storage is used.
  paths: 
    - 'df'
    - 'df.log'
  filters:
    - type: Exclude
      expressions:
       - '*empty*'
    - type: Extension
      expressions:
       - .ndjson
      - .csv
  # So, bean injection is decided here
    s3:
      bucket:
      region:
    blob:
      containers:
      connectionString:

여러 종류의 파일 스토리지 (type) 에서 특정 경로의 파일 또는 디렉토리 (path) 를
조건에 부합하는 (filters) 파일만 처리한다

위와 같은 목적을 같는 yaml 을 설계했다.

Java 애플리케이션은 이 yaml 을 읽고 동작을 시작해야한다.
이런 상황에서 선택할 수 있는 POJO Config class 전략으로 크게 2가지가 있다.

(1) Nested Class

첫째로 하나의 StorageConfig.java 클래스 내에 모든 클래스를 정의하는 방식이다.

@ConfigurationProperties(prefix = "storage")
public class StorageConfig {
    private String type;
    private List<String> paths;
    private List<FilterConfig> filters;

    private S3 s3;
    private Blob blob;
    private Local local;

    public static class S3 {
        private String bucket;
        private String region;
        // getters/setters
    }

    public static class Blob {
        private String containers;
        private String connectionString;
        // getters/setters
    }

    public static class Local {
    }
}

장점

• 단일 엔트리 포인트를 제공한다.
• Property - Value 매핑 관계가 한 눈에 들어온다.
• 따라서 이해하기 쉽다.

단점

• 내장 클래스가 늘어날 수록 클래스가 거대해진다.
• 모든 내장 클래스가 생성된다. (딱 하나만 사용한다 하더라도)
• 모든 내장 클래스가 커플링된다.
• 단 하나의 클래스를 지정하여 재사용하거나 테스트하기 껄끄럽다 (ex. S3, Blob 을 별도로)

(2) Separated class

하위 Property 를 매핑할 클래스를 모두 분리하여 정의하는 방식이다.

@ConfigurationProperties(prefix = "storage")
public class StorageConfig {
    private String type;
    private List<String> paths;
    private List<FilterConfig> filters;
    // getters/setters
}

@ConfigurationProperties(prefix = "storage.s3")
public class S3Config {
    private String bucket;
    private String region;
    // getters/setters
}

@ConfigurationProperties(prefix = "storage.blob")
public class BlobConfig {
    private String containers;
    private String connectionString;
    // getters/setters
}

@ConfigurationProperties(prefix = "storage.local")
public class LocalConfig {
}

장점

• 각각의 설정이 분리되어 SRP 원칙을 지킨다.
• 실제 사용할 클래스만 Bean 에 등록할 수 있다.

단점

• 클래스 개수가 많아진다.
• 클래스가 쪼개져 있기 때문에 Yaml -> Class 매핑 관계가 한눈에 들어오지 않는다.

설계 원칙

다음은 일론머스크의 엔지니어링 5단계다.

1. 모든 요구사항을 의심하라
2. 문제를 단순화하라.
3. 불필요한 요소를 제거하라.
4. 최적화하라.
5. 자동화하라

이 중 1,2,3번에 대해 스스로 자문자답해본다.

요구사항을 의심하라

Yaml 에 선언적으로 애플리케이션 동작을 정의하는 것이 필요한가?
-> 필요하다. Code 를 변경하지 않고 행위를 변경하게 지원할 수 있다.
ex) 특정 파일 확장자만 처리.

문제를 단순화하라

Yaml 을 심플하게 vs class 를 심플하게
-> Yaml 을 심플하게 하는 것이 최선이다.

Configuration POJO class 는 외부(yaml) 과 맞닿은 가장 저수준 레이어다.
Configuration class 복잡도가 증가하는 것은 감수할만 하다.
사용자들은 이 코드를 읽고 해석할 필요가 없기 때문이다.
사용자들은 오로지 yaml 사용법만 알면 된다.

가장 중요한 목표는 사용자들이 쉽게 yaml 을 선언하고 애플리케이션을 구동하게 하는 것이다.

불필요한 요소를 제거하라.

결론

규모가 작은 애플리케이션이고 설정 값이 추가될 여지가 적다면 Nested class 방식을 사용해도 좋다.
앞으로 새로운 항목이 추가된다고 예상된다면 Separated class 방식을 사용하길 권한다.