스프링 입문 - 비즈니스 요구사항 정리

회원 관리 예제를 만들어 볼 것이다.

먼저, 비즈니스 요구사항을 정리를 할 것이고,

그다음, 회원 도메인과 회원 객체를 저장하고 불러올 수 있는 저장소라고 불리는 리포지토리를 만들 것이다.

그리고 회원 리포지토리가 정상 동작하는지 테스트 케이스를 작성할 것이고,

실제 비즈니스 로직이 있는 회원 서비스를 만들고 이것이 정상적으로 동작하는지 테스트를 만들 것이다.
이때, 테스트는 Junit이라는 테스트프레임웍을 이용해서 만들 것이다.

이번시간에는 비즈니스 요구사항을 정리할 것이다.

 

비즈니스 요구사항 정리

이번 예제에서 비즈니스 요구사항은, 정말 간단한 것으로 할 것이다.

• 데이터 : 회원 ID, 이름
• 기능 : 회원 등록, 조회
• 아직 데이터 저장소가 선정되지 않음(가상의 시나리오)

 

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

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

이렇게 이루어져 있다.

이번 예제에서는 이러한 일반적인 웹 어플리케이션 계층 구조를 따라 갈 것이다.

 

클래스 의존관계는 회원 비즈니스 로직에 있는 회원 서비스(MemberService)가 있고,
회원을 저장하는 MemberRepository는 인터페이스로 설계할 것이다.
왜냐하면, 앞서 비즈니스 요구사항에 가상의 시나리오로 주어진 조건으로 "아직 데이터 저장소가 선정되지 않음" 이 있기 때문에, MemberRepository는 인터페이스로 만들고 구현체를 MemoryMemberRepository(메모리에 저장할 수 있도록 간단하게 작성할 수 있는 것)로 만들 것이다.
즉 인터페이스로 설계하고, 구현체를 단순한 구현체를 만들고, 향후에 구체적인 기술이 선정이 되면, 이것을 바꿔 끼울 것이다.
이때 바꿔 끼우려면 인터페이스가 필요하다.  그래서 인터페이스로 설계한다.