앞서 웹 개발 방법을 비교 학습해보았습니다. 이번에는 아주 간단한 회원 관리 예제를 통해 실습을 해보겠습니다. 개발 순서은 다음과 같이 진행하겠습니다.

  • 비지니스 요구사항 정리
  • 회원 도메인과 리포지토리 만들기
  • 회원 리포지토리 메모리 구현체 테스트
  • 회원 서비스 개발
  • 회원 서비스 테스트

 

비지니스 요구사항 정리

  • 데이터: 회원ID, 이름
  • 기능: 회원 등록, 조회
  • 데이터 저장소는 미정인 시나리오를 가정하고 개발 시작

 

일반적인 웹 어플리케이션 계층 구조

  • 컨트롤러: 웹 MVC의 컨트롤러 역할
  • 서비스: 핵심 비지니스 로직 구현
  • 리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리
  • 도메인: 비지니스 도메인 객체. 예) 회원, 주문, 쿠폰 등을 주로 데이터베이스에 저장하고 관리됨

클래스 의존관계

  • 데이터 저장소가 미정인 상황임으로, 우선 인터페이스로 구현 클래스를 변경할 수 있도록 설계
  • 데이터 저장소는 RDB, NoSQL등 다양한 저장소를 고민중인 상황으로 가정
  • 개발을 진행하기 위해서 초기 개발 단계에서는 구현체로 가벼운 메모리 기반의 데이터 저장소 사용

 

회원 도메인과 리포지토리 만들기

객체, 리포지토리 인터페이스, 리포지토리 구현체를 만들어줍니다. 

  • Optional: Java 8 의 기능, null 처리 방법, Null이 될 가능성이 있을경우 Optional.ofNullable 을 감싼다
  • MemoryMemberRepository 에서 저장하기 위한 변수 생성
    • 공유되는 변수일 때에는 동시성 문제가 있을 수 있기 때문에 실무에서는 concurrent 해시를 사용해야지만, 예제임으로 HashMap으로 진행
  • 마찬가지로 sequence도 Long이 아니라, Atomic Long을 사용해야하지만 예제임으로 그냥 Long 사용
  • findByName
    • Java 8의 Lambda 사용

 

회원 리포지토리 메모리 구현체 테스트

개발한 기능을 실행해서 테스트할 때 자바의 main 메소드를 통해서 실행하거나 웹 어플리케이션의 컨트롤러를 통해서 해당 기능을 실행한다. 이러한 방법은 준비하고 실행하는데 오래 걸리고, 반복 실행하기 어렵고 여러 테스트를 한번에 실행하기 어렵다는 단점이 있다. 자바는 JUnit이라는 프레임워크로 테스트를 실행해서 이런한 문제를 해결한다.

  • Assertions
    • org.assertj.core.api.Assertions.*;가 사용이 편리하여 잘 이용되며, static으로 import하여 쓰면 assertThat과 같은 기능을 바로 사용하기 편리하다.
  • 테스트는 순서와 상관없이 서로 의존 관계없이 설계되어야 한다. 따라서, 하나의 테스트가 끝나면 저장소와 같은 공유되는 것을 초기화 해주어야한다. 그러므로 @AfterEach를 사용해 repository를 지우도록 한다.
  • 테스트 케이스를 먼저 작성하고 클래스를 만들어 동작을 확인 하는 방식을 TDD라고 한다.

 

회원 서비스 개발

  • 비지니스 로직을 작성한다.
    • 회원 이름 중복 검증로직을 작성하는데, 이를 함수화하면 재사용성을 높일 수 있다.

 

회원 서비스 테스트

  • 서비스에서 테스트 만들기를 통해 쉽게 만들 수 있다.
  • 서비스 테스트 리포지토리가 서로 다른 객체인 것을, 서비스에서 MemberRepository를 직접 생성하는 것이 아니라 외부에서 넣어주도록 변경
  • 이러한 것을 DI (Dependency Injection)라고 한다.

이 글은 김영한 님의 스프링 입문 강의를 복습하기 위해 작성된 글 입니다.

참고: https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%9E%85%EB%AC%B8-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8

+ Recent posts