소개
•
군대 내 인원 관리 및 상 하향식 업무 전달, 상황전파 등의 시스템을 DX하기 위한 통합 솔루션입니다.
•
관리자 프론트엔드, 사용자 프론트엔드, SaaS 계정 및 결제용 테넌트 백엔드, 메인 백엔드로 구성되었습니다.
사용 기술
•
Kotlin, Springboot, MariaDB, MongoDB
진행 업무
아키텍처 선정
•
사내 스터디를 통해 헥사고날 아키텍처에 대한 학습과 이를 적용한 설계를 진행해봤습니다.
•
위 활동을 통해 도메인 로직과 InputPort, OutputPort를 완전히 분리할 수 있고, 상황에 따라 InputPort 및 OutputPort의 구현를 변경하여 유동적으로 대응할 수 있는 점이 매력적이었습니다.
•
해당 프로젝트는 기획상 각 테이블에서 유동적인 컬럼 생성, 수정, 삭제를 원했지만 회사 정책으로 RDB 사용이 강제되었습니다.
•
이로 인해, Persistence 관련 구현을 유연하게 변경할 수 있도록 하는 구조가 필요했습니다.
◦
실제로 구현의 유연성이나 도메인 로직의 완벽한 독립이 가능한지 느껴보고 싶었기에 “헥사고날 아키텍처”를 적용해봤습니다.
고화질 사진: 휴클로 밀리터리 백엔드 에그리거트 다이어그램.jpeg
◦
각 도메인 별로 어플리케이션 로직은 {도메인} 모듈이 있고,
이를 InputPort 성격에 따른 각 모듈에서 import해 로직을 사용했습니다.
◦
REST API Controller로 InputPort를 구현한 모듈은 {도메인-api},
Scheduler을 통해 InputPort를 구현한 모듈은 {도메인-batch},
MQ Consumer를 통해 InputPort를 구현한 모듈은 {도메인-processor}
로 명명했습니다.
MSA로 리펙토링
•
자사의 타 서비스들과 같은 계정정보를 사용하기 원하는 요구사항이 있었습니다.
•
또한, 각 유저별로 구독 여부에 따라 제공되는 서비스가 다른 Saas(Software as a Service)로 제공되어야 했습니다.
◦
결제와 사용자 모듈을 분리하여 테넌트 서비스 만들고, 기존 서비스를 메인 서비스로 해서 MSA 아키텍처로 구성했습니다.
◦
두 서비스의 통신은 동기방식 REST API로 진행하였습니다.
TDD 개발
•
QA 기간을 줄이고, 개발단계에서 신뢰되는 코드를 작성하고자는 니즈가 있었습니다.
◦
로직 구현 전 정상동작 케이스를 정의해 놓고 실제로 구현했을 때 케이스대로 구동되는지 바로 확인할 수 있는 TDD(Test-Driven Developemt) 방식을 사용했습니다.
◦
자사 다른 서비스들에 비해 QA 기간이 훨씬 짧았고, 높은 신뢰성을 가진 코드를 작성할 수 있었습니다.
회고
•
헥사고날 아키텍처로 개발해보니 레이어드 아키텍처에 비해 초반 세팅과 개발 속도가 더뎠지만 차츰 익숙해지고 나아져서 실제 도입해 사용하기 괜찮은 것 같습니다.
•
1차 개발 완료 후 DB를 MongoDB로 전환할 때 헥사고날 아키텍처의 장점을 최대한으로 느낀 것 같습니다.
◦
각 OutputPort에 대한 구현체를 MongoDB 에 맞춰 구현하고, 서비스가 작동하는 것을 보고 개발에 대한 쾌감을 느꼈습니다.
