비즈니스 요구사항에 따라 설계.

회원

회원 entity

• 회원 등급 enum
• id, name, grade 필드
• 생성자, getter setter

회원 repository

1. 인터페이스

• save()
• findById()

2. 구현체

private static Map<Long, member> store = new HashMap<>();

필드 가짐.

• 아래에는 save, findById 구현.

회원 service

1. 인터페이스

• join()
• findMember()

2. 구현체

private final MemberRepository memberRepository = new MemoryMemberReposotory();

가짐.

• join, findMember 구현.

회원 도메인 테스트

1. MemberApp 통한 테스트
   but, 애플리케이션 로직으로의 테스트 좋은 방법 X. JUnit 테스트 사용

2. JUnit 테스트

• 테스트 하려는 메서드를 만들고, @Test 어노테이션 붙여줌.
• 테스트 과정은 given, when, then 틀 이용.

문제 : OCP, DIP가 지켜지고 있지 않음.

• repository 구현체를 변경한다면 그 윗 단의 service의 코드도 수정해야함.
  -> 의존관계가 인터페이스 뿐만 아닌 구현체까지 의존.

---

주문과 할인

할인 정책

1. 인터페이스

• discount()

2. 구현체

• 필드 discountFixAmount = 1000;
• discount() 구현 -> getGrade() == VIP 일 시 discountFixAmount 반환. 아닐 시 0 반환.

주문 엔티티

• 필드 : memberId, itemName, itemPrice, discountPrice
• 생성자, getter setter
• toString() -> 객체 출력시 객체의 값까지 반환.

주문 서비스

1. 인터페이스

• createOrder()

2. 구현체

필드 :

private final MemberRepository memberRepository = new MemoryMemberRepository();
private final DiscountPosicy discountPolicy = new FixDiscountPolicy();

생성 이유 : Order에 discount값 넣어줘야함 -> discount값 얻으려면 discount()에 member 넘겨줘야함 (discountPolicy 생성) -> 그러려면 member 객체 얻어야함(memberRepository 생성)

주문과 할인 정책 테스트

1. OrderApp 통한 테스트

2. JUnit 통한 테스트
   과정 : 1. member 생성 2. memberService.join()3. orderService.createOrder()

---

내 고민들

1. Test에서, createOrder memberId만 받잖아. 그럼 굳이 Member객체를 만들지 않아도 통과 되는거 아니야?
   -> createOrder 메서드 안의 코드 보면, findById로 member 객체를 찾음. 그렇기에 만들어두지 않으면 member를 찾지 못할 것이고 null에러 날 것임. 놓친 것은, 그 안의 로직을 생각하지 않은 것.

2. 주문에서, 할인 정책 fix-rate 선택 못해서 discount interface 만들었잖아. 그럼 만약 fix만 하기로 선택했다면 굳이 discountPolicy interface 안만들고 orderService에 할인해주는 메서드 만들어도 될까?
   -> 안된다고 결론내림. SRP 때문. 이는 변화를 고려한 것. 만약 orderService에 fix 넣었다가 나중에 변동 있을시 파급효과 존재함. 그렇기에 구별해야 한다.

3. @Override 어노테이션 없어도 실행 되는데 왜 달까?
   -> 만약 메서드명을 틀릴시 이를 알려줌. 만약 어노테이션 없이 했다면, 상속이 아닌 또다른 함수로 알아버릴 수도 있음. 이를 방지.
   또한 유지보수시 상속된 메서드임을 알 수 있으므로 생산성 올라감.

고민들로부터 얻은 느낀점

자바와 스프링에 있는 기술들은 진보보단 안정을 중요시한다고 느꼈다. 화려한 공격이 아닌, 매우 안정적인 방어 구축을 지향하는 것.