Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까? 이전 글에서 OrderService에서 의존하고 있는 컴포넌트가 너무 많아 응집도가 떨어지고 강결합이 발생하는 문제가 있었다고 언급을 했었습니다. 그래서 이번엔 facade pattern을 E-commerce 서비스에 적용하여 리팩터링 한 내용을 정리해보려고 합니다. 기존 OrderService 코드 public class OrderService { private final UserReader userReader; private final UserPointManager userPointManager; private final UserPointValidator userPointValidator; private fin..

주문 결제 트랜잭션 단위를 어떻게 가져가야 할까 이번에 이커머스 서비스를 만들면서 주문 결제 트랜잭션 단위를 어떻게 설계할 것인지에 대해 고민을 많이 하게 되었습니다. 우선 이 서비스에서 결제는 별도의 pg사를 연동하지 않고 user 테이블에서 point를 관리하여 이 point로 결제를 하는 서비스입니다. 주문 결제 트랜잭션을 분리하는 방안과 하나의 트랜잭션으로 가져가는 2가지 방안에 대해 어떤 방법이 더 적절(?)한 지 고민하고 생각했던 내용을 정리해보려고 합니다. 사실 "이 방법이 무조건 맞아!" 같은 정답이 없다는 건 머리로는 알지만 이런 선택을 해야 할 때는 누군가 정답을 줬으면 좋겠다는 마음이 있습니다. 아직까지는 트레이드 오프하는 게 쉽지 않은 것 같습니다.. 주문 결제 트랜잭션 분리 우선 ..

E-Commerce 서버 구축 시작3주 차 과제는 3주간 서버 구축을 진행할 3개의 시나리오 중 하나를 선택하여 요구사항을 분석하고 관련 문서(시퀀스 다이어그램, ERD, API 명세 등등)를 작성하는 게 과제였다. 문서 작업이 중요하다는 것은 알지만 아직까지도 제일 하기 어렵고, 귀찮은 작업이였다. 귀찮게 느껴지는 이유 중 가장 큰 이유가 ERD 설계나 API 명세를 미리 작성을 해두면 처음부터 끝까지 수정이 되지 않으면 좋겠지만 어쩔 수 없이 중간 중간 수정이 불가피하게 발생하는데, 이 작업이 반복되어 귀찮게 느껴지는 것 같다. 그래서 프로젝트 시작 전 하는 설계에서 개발자로서 역량이 드러난다고 생각이 되었다. 아무튼 나는 이번 과제에서 e-commerce 서버 구축 과제를 선택했다. 다른 2개는 ..

개발을 하다 보면 “도메인”과 “엔티티”라는 용어는 한 번씩 듣게 된다. 그런데 누구는 도메인을 엔티티와 비슷한 개념으로 사용해서 이야기하는 것 같고, 누구는 도메인과 엔티티는 다르다! 라고 말을 하는 것을 종종 볼 수 있다. 나 또한 그랬고 두 개념이 어떻게 다른지, 실상 모르고 용어를 사용했었다. 결론부터 말하면 내가 이해한 도메인과 엔티티는 같은 의미로 사용될 수도 있고 아닐 수도 있다. 얘가 지금 무슨 소리 하는 거지 할 수 있다.. 우선은 도메인과 엔티티는 내가 만들려는 애플리케이션의 아키텍처 설계에 따라 달라질 수 있다. 즉, 어떻게 설계했느냐에 따라 사용되는 용어의 의미가 달라질 수도 있고 같아질 수도 있다. 그래서 도메인, 엔티티 이야기를 할때는 맥락파악이 중요하다. 2가지 케이스로 나눌 ..

Clean + Layered Architecture이번 2주 차 과제는 아키텍처 설계가 중점인 과제를 진행했다.평소 애플리케이션을 구성할 때 아키텍처 설계 없이 무지성으로 Layered Architecture로 설계하여 애플리케이션을 만들었었는데, 이번 과제를 진행하면서 다양한 아키텍처에 대해 배울 수 있었다. (Layered, Clean, Hexagonal, Clean + Layerd)  이제껏 무지성으로 설계해 왔던 아키텍처를 실제 애플리케이션을 만들 때, 어떻게 아키텍처를 설계할지 고민하며 "이렇게 설계했을 때의 장점이 무엇이지?", "기존에 내가 설계했던 방식은 이러한 문제점이 있었구나" 같은 생각들을 정리하고 몸으로 직접 느낄 수 있었다. 가장 크게 배운 부분은 "하위 계층의 변경은 상위 계층으..

한 주를 돌아보며 회고를 작성합니다  TDD1주차는 TDD로 point 이용 / 충전 관련 애플리케이션을 만드는 과제를 진행했다.평소 개발 방식이 기능 구현 → 테스트 작성 순이었는데, 역순으로 테스트 코드 작성을 먼저 하려니 어색하고 생각해야 할 부분이 많았다.어떤 기능을 구현해야 하는지 요구사항을 정확히 파악해야 테스트 코드를 작성할 수 있는데, 테스트 코드를 먼저 작성하면서 하나의 시나리오를 구성한다고 생각하면 편했다.예를 들어 포인트를 충전하는 기능을 구현한다면, 테스트 코드를 아래의 흐름으로 먼저 작성할 수 있다.포인트를 충전할 사용자의 정보를 준비한다.해당 정보의 사용자에 포인트를 충전하는 메서드를 호출한다.메서드의 결괏값이 내가 예상한 결괏값과 일치한지 검증한다.테스트 코드를 작성할 때, 검..