Kobalttown에 대해서
Kobalttown은 Micro API 플랫폼 개발 프로젝트이다. 애플리케이션은 많아도 사용하는 유틸리티나 DB는 분야에 따라 대표적인 몇 개만 사용해서 만들 수 있는 것 처럼, 공통 기능은 플랫폼 기능을 사용하고 애플리케이션에 필요한 기능만 개발해 플러그인처럼 끼워넣어 사용할 수 있는 API 플랫폼을 목표로 한다.
목표
표준화로 코드, 구조, 관리, 분석의 일관성을 달성해 모든 것은 코드로 관리한다.
- 계정 관리 등의 일반적인 기능은 애플리케이션에 설정과 라이브러리 의존성을 추가하는 것으로 사용 가능하도록 만든다.
- 소스 구조의 표준을 제시한다.
- 환경 독립적은 설정은 소스코드에 포함시켜 개발도구의 소스 관리 기능을 사용할 수 있도록 한다.
- 환경 종속적인 설정은 구조와 접근 방식을 표준화한다.
수단
- 어노테이션을 사용한 JavaConfig를 기본 설정 방법으로 사용한다.
- 독립적으로 사용할 수 있는 소스 레이어를 기준으로 모듈을 나눈다.
- 각 모듈은 하나의 루트 패키지를 가진다.
- 각 모듈은 코드 레이어에 따라 패키지를 구분한다.
- 각 모듈이 사용하는 설정은 YAML을 사용하며, 모듈의 패키지 이름을 접두어로 사용한다.
- 패키지, 클래스 이름 등 코드 자체에 대한 정보가 필요할 경우엔 어노테이션에 직접 하드코딩하지 않고 별도의 상수를 사용한다.
주저리
만들고 싶은 것은 많고, 해봐야 할 것도 많은데 업무로는 선택의 폭이 뻔한데다 만들 때마다 이런저런 이유로 거의 같지만, 호환되지 않을 만큼만 다른 것을 반복해서 만들어야 하는 게 짜증나서 만들기 시작했다. 만들다보니 지나치게 많은 모듈과 레이어와 인터페이스와 클래스와 덩달아 복잡한 상속구조가 튀어나왔다.
지금은 과도한 구조인 것 같지만, 단일 책임 원칙 면에서 인터페이스, 패키지, 모듈의 분리는 적절하다고 생각한다. 복잡한 상속 구조는 지나친 것 같기도 하지만 판단은 일단 뒤로 미룬다. 모듈 분리는 테스트 대상 레이어에 따라 설정을 달리해야 하는 문제로 시작했다. 특히 문제가 됐던 부분은 같은 모듈에서 서비스 레이어 테스트와 통합 테스트의 설정이 문제였다. 테스트 클래스의 설정을 서비스 레이어에 맞추면 통합테스트가 작동하지 않고, 통합테스트에 맞추면 서비스레이어의 테스트가 작동하지 않는 식이었다.
거의 비슷하지만 같지는 않은 기본 기능을 매번, 혼자 만드는(유일한 서버 개발자) 업무 구조가 짜증나 시작했지만, 마이크로서비스를 기본으로 하는 이 구조는 혼자 하나의 애플리케이션을 만들 때 채택할 구조가 아니다. 보안과 유저를 비롯한 데이터 관리 정책 같은 일반적이고 긴 시간을 기준으로 삼는 관심사의 담당자와 플러그인(애플리케이션 혹은 마이크로서비스) 담당자가 서로 다른 사람인 업무 구조가 전제 조건이다.
보다 엄격하고 조심스러운 보수적 접근이 필요한 기업 목표나 고객을 바라보는 관점에 대한 부분과 시장에 민감하게 반응할 필요가 있는 기능에 대한 부분을 분리해서 일정과 기능, 품질 목표를 개발 이슈에 따라 보다 적절하게 설정할 수 있는 기반을 갖추기 위한 구조이다.
그러니까, 계정 등록이나 인증이나 게시판 같은 평범한 기능은 한 번 만들고 신경 끄고 싶었다.
참고 : Kobalttown 계정 브랜치