Dayner 2차 리팩토링 계획(feat: 멀티 모듈화)

기획부터 운영까지 반년이 넘어가는 시점이다.

초기 계획에 비해 규모가 커지고 있다. 새로운 디자이너 영입(결정 과정이 쉽지는 않았다)과 프론트엔드 인원 충원으로 작업이 시작되었으며, 디자인이 새로워졌다.

 

새 디자인! 역시 전문가는 다른것같다..

 

 

원래 계획과 현재 기능을 비교하자면 아래와 같다.

 

 

원래 계획과 현재 기능을 비교해 보면, 기능 확장이 있었고 앞으로 2호점도 생길 예정이며, 토스 결제 기능이 추가된 주문 기능도 포함될 예정이다.

 

 그러나 현재 코드 구조에서는 서로 관련이 없는 코드들이 하나의 패키지에 모여 있어, 새로운 기능을 추가하거나 유지보수할 때 불편함을 느낀다.

처음 계획했을때의 기능과 현재의 기능(포장 주문의 경우에는 구현 예정이다)

 

---

모듈화의 필요성

따라서, 모듈화를 통해 코드를 분리하고 관리하기로 결정했다.

 

 최근 회자 되고 있는 DDD(Domain-Driven Design)나 MSA(Microservices Architecture)와 같은 접근 방식을 고려할 수 있는데, 계속 연락을 주고 받고 있는 동아리원의 말에 따르면 요새 협업 프로젝트로도 대용량 처리를 염두한 다중 서버를 구축한다고도 한다.

 

하지만 실제 운영 환경은 이상적이지 않다. 현재의 상황에서는 여러 대의 API 서버를 두고 운용하기보다는, 부하가 걸리는 API의 경우 메시지 큐(Message Queue)를 사용할 필요 없이 Async로 처리하는 것이 대부분의 상황에서 충분하다. 이는 비동기 처리로도 대부분의 성능 요구 사항을 충족할 수 있기 때문이다.

---

 

향후 계획 및 고려 사항

 

2차 리팩토링을 수행하는 가장 큰 이유는 초기 단계에서 고려하지 않았던 포장 주문 기능의 추가와 2호점 개설에 따른 Stock 관리의 이중화 같은 요구 사항을 반영하기 위해서인데, 상품과 결제 모듈을 별도로 분리하면, 원두나 영업 일정과 같은 다른 도메인과도 격리되어 기능 추가나 수정 시 영향이 적고, 새로운 재고 관리 시스템 추가에도 용이할 것으로 판단된다.

 

 

현재로서는 결제 트랜잭션이 1000건 남짓 이지만, 추후 활성화로 인해서 데이터가 증가할 경우에는 결제 데이터 관리를 하는 모듈에서 개인정보법에 따라 주기적으로 파기, 보존 하는 배치 작업을 모듈로 구현하여 장점을 챙겨갈수 있을것 같다.

 

추가적으로, 필요한 경우 서버를 다중화하고 메시지 큐 등의 비동기 처리 기법을 고려할 수 있지만, 현재 상황에서는 복잡도를 줄이기 위해 Async 방식이 충분할 것으로 판단된다.

 

 

결론적으로는 아키텍처 설계에 대한 고민을 많이해봐야할것 같다. 성능을 유지한채로 유지보수성, 가독성이 좋은 이해하기 쉬운 구조를 생각해봐야겠다.