Gradle, SrpingBoot, Multi Module) Finance API 코드 구조 (v.1.0.0)
Multi Module ?
개발하다보면 부딪히는 문제들이 있습니다. 그러한 문제들은 소스코드의 유지보수를 어렵게 합니다. 빠르게 개발하고, 빠르게 출시하지 못하는 장애요소가 되죠. 결국은 고객들에게 우리의 서비스 가치를 전달하지 못하게 됩니다.
장그래의 실수
혹시 드라마 미생 보셨나요? 주인공 장그래에게 주어진 업무가 있습니다. 조직에서 진행중이던 업무 관련 파일들을 폴더트리에 맞게 정리하는 작업이었는데요. 조직에선 이미 사용중이던 폴더 트리가 있음에도 불구하고, 장그래는 자신의 방식에 맞추어 정리하게 됩니다. 이미 고착화된 폴더 트리는 업무에 방해요소가 된다고 판단했죠.
"장그래씨, 과장님께서 주신 폴더트리를 왜 전부 무시한거야?"
"무시한게 아니고, 그대로 하자니 넣기 애매한 파일들이 너무 많았어요."
"장그래씨, 그거 회사 메뉴얼이야. 그게 무슨 뜻인지 알아? 모두가 이해했고 약속했단 뜻이야. 회사 일 혼자 하는거 아니야."
같은 모양의 코드
코드 구조는 왜 필요 할까요? 비슷한 이유입니다. 협업하는 개발자들이 공감할 수 있는 소프트웨어 구조를 고민하고, 모두의 협업이 매끄러울 수 있도록 하나의 '도구'로서 작동합니다. 또는, 각 레이어를 침범하지 않도록 강제하는 역할도 함께 합니다. (중요!)
개인적으로는, 동일한 레이어에 있는 코드는 똑같은 모양을 갖도록 작성하는 편입니다. 가령, 비즈니스 로직과 무관한 'Controller'는 복잡한 코드가 작성되지 않았으면 합니다.
// 더 필요한 코드가 있을까요?
// 라우팅은 Framework가 책임지고 있고, 비즈니스 로직은 Service가 책임지고 있는 등.
// 책임 이상의 역할을 하지 못하도록 코드는 항상 강제되어야 합니다.
fun findUser(..) {
val request = Request.get()
val service = UserServier()
return service.findUser(request.toServiceDTO())
}멀티 모듈을 이용해서, 각 레이어의 책임을 명확하게 규정할 수 있지 않을까요?
Example
진행중인 프로젝트의 소스코드 구조입니다.
중복코드는 명시적으로 허용하는 편이고, 코드의 구조를 지키는 편이 훨씬 이롭다는 판단이 기저에 깔려있습니다.
Root Module
- Logger, Log Filter 등 비즈니스 로직과 아예 무관한 코드를 작성합니다.
- 비즈니스 로직에 관여하는 코드는 절대 작성하지 않습니다. 특히, 외부 API와 협업하는 소프트웨어라면 가장 유의해야하는 레이어입니다. 우리의 공통코드가 상대측 Server 응답에 종속되어선 안되니까요.
- String을 Date Type으로 변경하는 코드조차 넣지 않았습니다. Client Code의 책임이지, 우리의 공통 코드가 해결 할 일이 아니니까요.
- 개인적으론 Common(Helper)의 존재를 극히 꺼립니다. 대부분의 커플링 이슈는 Helper에서 발생하더라구요.
Http API Layer, Backed Job Layer
- API는 Controller와 Service를 작성하고, Backend Job은 Client Code와 Service를 작성합니다.
- 실제 비즈니스 로직이 수행되는 코드들이 작성됩니다. 두개의 레이어는 각각의 Service Layer를 보유하고 있습니다.
- API, Job에서 분명 동일하게 사용되는 로직이 존재할 수 있습니다. 그래서 Service Layer를 하나의 독립적인 레이어로 구분할까 고민이 굉장히 많이 되었는데요.
- 결국은 Helper와 동일한 문제들에 직면할 것 같아서, 각각이 스스로의 비즈니스 로직을 책임지도록 구성했습니다.
Data Layer
- RDBMS, Kafka, Cache를 위한 Redis 등과 관련된 코드가 작성됩니다.
- 실제 비즈니스를 수행하는 Service Layer만 참여하며, 역방향 참조는 절대 허용하지 않습니다.
