[스프링 핵심원리] 회원 - 주문 예제로 이해하기

김우경·2021년 1월 22일
0

Spring Framework

목록 보기
12/12
post-thumbnail

김영한님의 스프링 핵심 원리 - 기본편을 보고 공부한 내용입니다.

프로젝트 생성

https://start.spring.io/ 에서 아래와 같은 설정으로 generate !

TIP build시 gradle이 아닌 intellij를 이용해서 빌드하면 더 빠르다

비즈니스 요구사항과 설계

  • 회원
    • 가입 & 조회
    • 등급 존재 : 일반 / vip
    • 회원 DB는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다 → 미확정
  • 주문 & 할인 정책
    • 회원은 상품 주문
    • 할인 정책은 회원 등급에 따라 ⇒ VIP는 1000원씩 할인 적용 (나중에 변경 가능)
    • 할인 정책은 변경 가능성이 높다 → 미확정

→ 역할과 구현을 구분 : 인터페이스를 만들어서 구현체는 언제든지 갈아끼울 수 있도록 !!!!

순수 자바 코드로만 구성

회원 도메인 설계

요구사항

  • 가입과 조회 기능
  • 등급에는 일반과 vip
  • 회원 DB는 아직 미확정

도메인 협력 관계

  • 기획자도 볼 수 있는 그림
  • 요구사항 분석 과정에서 이해관계자들의 소통의 도구로 활용!

위의 요구사항에 따른 회원 도메인의 협력관계를 다이어그램으로 나타내면,

: 회원 db가 미확정이므로 회원에 접근하는 계층 "회원 저장소"를 따로 만들어 줘야 함을 알 수 있다 !

클래스 다이어그램

  • 도메인 다이어그램을 바탕으로 더 구체화한다.
  • 서버를 실제로 실행하지 않고 클래스의 의존 관계만 보고 그릴 수 있다.
  • 서버가 뜰때 동적으로 결정되는 부분은 클래스 다이어그램만으로 참고하기 어려움 !
    -> 이번 예제에서 클래스다이어그램만 봐서는 MemoryMemberRepository를 사용하는지 DbMemberRepository를 사용하는지 알 수 없음

객체 다이어그램

  • 동적으로 맺어진 객체들의 연관관계를 표현한다.
  • 실제가 서버가 떴을때 생성한 인스턴스끼리의 참조 표현

이 다이어그램들이 내가 아는 UML 다이어그램의 객체 다이어그램, 클래스 다이어그램과 같은 개념이 맞나 궁금해졌다. 질문을 드리려다가 같은 질문을 하신 분이 계셔서 답변을 참고했다.
결론적으로는 UML 표기법에 따른 다이어그램들이 아닌 이해를 돕기 위햇 의존 관계를 표현한 그림이라고 한다 ..!

TIP 인터페이스와 구현체는 다른 패키지에 넣는게 더 좋은 구조

회원 도메인 설계의 문제점

  • 다른 저장소로 변경했을때 OCP 원칙을 준수 ??
  • DIP를 잘 지키고 있는지?
    → 의존관계가 추상화와 구체화 모두에 의존하므로 DIP를 위반 ^_ㅠ!

주문과 할인 도메인 설계

요구사항

  • 회원은 상품 주문
  • 할인 정책은 회원 등급에 따라 ⇒ VIP는 1000원씩 할인 적용 (나중에 변경 가능)
  • 할인 정책은 변경 가능성이 높다 → 미확정 : 할인을 적용하지 않을 수도 있고, 기본 할인 정책은 아직 미정

서비스 요구사항의 큰 흐름은 아래와 같다.

  • 클라이언트는 주문 서비스에 주문 생성을 요청
    주문 서비스는 회원 저장소에서 회원을 조회해서 회원의 등급을 알아낸다
    → 주문 서비스는 등급에 따른 할인 여부를 할인 정책에 위임한다
    → 주문 서비스는 할인 결과를 포함한 주문 결과를 반환 (예제의 단순화를 위해서 주문 결과만 반환)

: 역할과 구현을 분리 → 자유로운 구현 객체 조립이 가능하도록

위의 요구사항을 토대로 만든 주문-할인 객체 다이어그램은 아래와 같다.

→ 회원을 저장하는 DB가 바뀌거나 할인정책을 변경해도 주문 서비스를 변경하지 않아도 됨
: 역할들의 협력 관계를 그대로 재사용할 수 있음

출처

김영한님의 스프링 핵심 원리 - 기본편을 보고 공부한 내용입니다.

profile
Hongik CE

0개의 댓글