[E-commerce] 프로젝트 회고

프로젝트 선택

E-commerce 서버 구축 프로젝트를 통해, 다양한 기술적 문제와 해결 방안을 경험할 수 있었다. 
프로젝트의 선택 과정부터 구현까지, 트랜잭션 관리 방안, 이벤트 기반 아키텍처 구조로의 전환과 같은 문제들을 다루면서 평소에 경험할 수 없었던 내용들을 학습하면서 프로젝트를 진행했던 것 같다.

처음에는 문서 작업부터 시작했는데, 프로젝트 초기 단계에서는 문서 작업의 어려움을 많이 느꼈다. 특히, 변경이 잦은 ERD와 API 명세의 수정이 반복되어 힘든 부분이 있었지만, 실제 개발을 진행하는 과정에서 초기 프로젝트 설계의 중요성과 필요성을 인식할 수 있었다.

 

트랜잭션 처리의 고민과 해결

이번에 이커머스 서비스를 진행하면서 가장 시간을 많이 소비했던 부분이 주문 결제 시스템의 트랜잭션 처리 였다. 

처음엔 주문과 결제를 분리해서 처리하는 방식으로 접근하였지만, 이후에는 이를 하나의 트랜잭션으로 처리하는 방식으로 변경하여, 동시성 처리와 구현 복잡성을 줄이는 방법을 택하게 되었다.

후반에는 이벤트 기반 아키텍처로 전환하면서 다시 분리하는 방법으로 가게 되었지만 두가지 방법을 직접 구현해 보고 각각의 특징에 대해 경험할 수 있었다.

https://seungjjun.tistory.com/322

[E-commerce] 주문 결제 트랜잭션 단위를 어떻게 가져가야 할까

 

Facade 패턴의 적용과 시스템 응집도 향상

기존에 서비스 계층에서 비즈니스 로직이 구현된 여러 컴포넌트들을 조합하는 형태를 Facade 패턴을 적용하여 facade 계층에서 서비스의 관심사별로 호출하여 훨씬 깔끔하고 관리하기 쉬운 코드 리팩터링을 진행했다. 
facade 패턴 덕분에 시스템의 응집도가 매우 향상되었고, 코드 재사용성도 높아지는 것을 경험했는데, 평소 '디자인 패턴'에 대해 무지했었는데 이번에 디자인 패턴이 왜 중요한지, 실제로 적용해 보면서 알게 되었다.

결론적으로 Facade 패턴을 적용하여 시스템의 응집도와 재사용성을 개선하는 경험을 통해, 복잡한 시스템의 관리가 용이해질 수 있음을 체험했다.

https://seungjjun.tistory.com/323

[E-commerce] Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까?

 

비동기 처리와 이벤트 기반 아키텍처의 도입

프로젝트 후반부에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서, 시스템 간의 결합도를 낮추고 독립적인 트랜잭션 관리하도록 변경하는 작업을 진행했다.
이 부분은 아직 진행 중이라 추후 더 자세히 글을 작성해보려고 한다.

이벤트 기반 아키텍처를 적용했을 때 기대되는 효과로 시스템의 확장성과 유지보수성을 향상시키고, 트랜잭션을 독립적으로 관리할 수 있다는 정도인데 아직 직접 경험하지 못하여서 이벤트 기반 아키텍처가 좋은지에 대해서는 아직도 의문이다.

 

https://seungjjun.tistory.com/328

[E-commerce] 주문 결제를 이벤트 기반 아키텍처로 구축하기

 

마무리

이커머스 프로젝트는 개인적으로 많은 성장을 경험한 시간이었다. 
테이블 설계, 패키지 구조, 아키텍처 설계, 트랜잭션 관리, 동시성 처리 등등 평소 실무에서나 개인 프로젝트에서는 당연시 넘어갔던 부분이나 경험하지 못했던 부분들을 하나씩 고민하고 해결하는 과정을 통해 3주 전의 나보다 한층 더 성장했음을 느끼고 있다.

솔직히 동시성 처리나 주문 결제 시스템이 완전하다고 생각하지 못해 만족하지는 못해서, 이 부분은 개인적인 시간을 더 투자해 조금 더 발전시켜나갈 예정이다.

처음엔 3주가 길다고 느껴졌지만 실제로 진행해보면서 3주가 시간이 부족하다고 느껴져 힘들었지만, 많은 것들을 배울 수 있었던 프로젝트였다.