발자국남기기

현재 AppConfig에는 중복이 있고, 역할에 따른 구현이 잘 보이지 않는다. MemoryMemberRepository가 중복되어 사용되고 있음. 메소드로 꺼내어 사용 또한 어떤 역할(인터페이스)를 사용하여 구현을 했는지가 보이지 않는다. MemoryMemberRepository는 MemberRepository의 역할을 수행하는데 그것을 확인할 수 없음. 👇 👇 다음과 같이 중복을 제거하고 메소드를 추출하였다 어떤 역할(인터페이스)에서 어떤 구현체를 사용한 것인지 한 눈에 확인할 수 있다. 이는 만약 회원 저장소가 변경될 때 (DB를 사용하거나 jdbc를 연동할 때) memberRepository안의 구현체만 변경해주면 된다. 전체 애플리케이션의 구성이 어떻게 되어있는지 파악가능 정액 할인을 정률 할인..

현재 작성된 코드는 주문서비스 구현체(OrderServiceImpl)가 할인 정책 구현체를 선택하고 있는 상태이다. (FixDiscountPolicy / RateDiscountPolicy) 이를 공연에 대입해보자. 공연은 각 배역이 있고 그에 맞는 배우가 있다. 이를 매칭시켜보면 공연 = 애플리케이션(비지니스 로직 전체) 배역 = 인터페이스 (OrderService, DiscountPolicy) 배우 = 구현체 (OrderService, FixDiscountPolicy / RateDiscountPolicy) 배우가 상대 배역의 배우를 선택하고 있는 것과 똑같은 상황이라 할 수 있다. 즉, 배우가 공연도 해야하고 상대 배역까지 정해야하는 다양한 책임을 가지고 있음. 즉, 우리에게는 공연 기획자같은 역할에 ..

1. 할인 정책 변경 👇 👇 😡😡문제점😡😡 역할과 구현을 충실히 분리했음. 다형성도 활용, 인터페이스와 구현 객체를 분리했음. BUT # DIP 클래스 의존관계를 보면 OrderServiceImpl은 추상(인터페이스)뿐만 아니라 구체(구현)클래스에도 의존하고 있다. 추상 : DiscountPolicy 구체 : FixDiscountPolicy / RateDiscountPolicy 우리가 설계한 의존 관계 실제 의존 관계 클라이언트인 OrderServiceImpl이 인터페이스와 구현체를 함께 의존하고 있다. DIP 위반❌❌❌ # OCP 기능을 확장하여 변경하려고하면, 클라이언트 코드에 영향을 준다. (FixDiscountPolicy를 RateDiscountPolicy로 수정) 할인 정책을 정액할인에서 정률할..

🦹‍♂️요구사항🦹‍♂️ 기존 할인 정책 = 정액 할인 정책(고정 금액) : VIP 무조건 1000원 할인 정률 할인 정책(% 할인)으로 변경하고 싶음 10%할인 10000원 주문시 1000원 할인, 20000원 주문시 2000원 할인 1. 새로운 정책 구현하기 2. 새로운 정책 테스트 새로운 회원객체를 생성하여 할인금액을 return 받아 discount에 저장 Assertions를 사용하여 1000원인지 검증 @DisplayName은 Junit5부터 지원하는 애노테이션으로 테스트 명을 지정해줄 수 있다. 테스트 성공!(오타가 있네..디X 되O) 👯‍♂️테스트를 만들 때에는 성공 테스트 뿐아니라 실패 테스트도 꼭 만들어봐야한다.👯‍♂️ Expected (기대값) = 1000원 Actual (실제값) = ..

1. java main메소드로 실행 / 테스트 memberService를 통해 새로운 회원을 가입시킴 orderService를 통해 새로운 주문을 생성하여 order에게 넘겨준다. 주문서비스 구현체에서 멤버 등급을 확인해 할인 금액까지 알려줌 테스트 성공! 2. Junit으로 테스트 멤버 서비스를 통해 새로운 회원을 join시킴 주문 서비스를 통해 새로운 주문 생성 Assertions의 assertThat메소드를 사용하여 할인 가격이 1000원이 맞는지 검증 새로 join된 회원의 등급이 vip이므로 할인가격은 1000원이어야함. 테스트 성공! 3. 전체 테스트 성공!

주문과 할인 도메인 설계 설계 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있 다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다. 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회 한다. 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다. 주문 결과 반환: 주문 서비스는 할인 결과를..

1. 자바 코드로 테스트 해보기 join이 정상적으로 수행되어 메모리저장소에 저장된 것을 확인할 수 있다. spring관련 코드 X 오로지 java로만 테스트 하지만 애플리케이션 로직 main으로만 테스트하는 것은 한계가 있음. 스프링 입문에서 다루었던 Junit으로 다시 테스트 해보자 2. Junit 사용해서 테스트 Assertions의 assertThat메소드를 사용해 findMember를 통해 찾은 정보와 member 객체의 정보를 비교한다. 테스트 성공 회원 도메인 설계의 문제점 이 코드의 설계상 문제점 다른 저장소로 변경할 때 OCP 원칙을 잘 준수할까요? DIP를 잘 지키고 있을까요? 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있음 MemberRepository(인터페이..

회원 도메인 요구사항 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수도 있고, 외부 시스템과 연동할 수도 있다.(미확정) 회원 저장소 인터페이스를 만들어 놓고 각각의 구현체를 만들어 갈아끼우는 형식으로 진행 클래스 다이어그램은 실제 서버를 실행하지 않고 클래스만 분석해서 나타낸 그림 ==> 정적 구현체인 MemoryMemberRepository / DbMemberRepository 중 어떤 걸 선택할지는 동적으로 선택해야함. MemberRepository memberRepository = new MemoryMemberRepository(); 로 결정하는 것을 의미 따라서 이것만으로 판단하기는 어려움 그래서 객체 다이어그램을 통해 실제 어..

비지니스 요구사항과 설계 회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정) 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라.(차후에 변경 될 수 있음.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다.(미확정) 요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때까지 개발을 무기한 ..

앞서 스프링 입문을 통해 스프링이 어떤 것이며, 스프링 컨테이너 / 스프링 빈/ 의존성 주입 등을 간략히 알아보았다. 이제는 스프링의 세부적인 내용과 왜 스프링을 사용해야하는지에 대해 알아보려한다. 먼저, 비지니스 로직을 설계하고 이를 순수 JAVA만으로 구현할 것이다. 그 후, 비지니스 로직에 변경이 필요할 때 순수 JAVA만을 사용한 다형성으로 객체지향설계 원칙인 SOLID를 지킬 수 있는지를 확인해보고 스프링이 왜 필요한지에 대한 근본적인 이유에 대해 알아 볼 것이다. 또한, 간략히 다루어보았던 Spring Bean, Spring Container, DI등에 대해 자세히 다루어 보려고 한다.