2-3. 회원 도메인 설계

프로그램의 구성요소들이 어떻게 생겼고 서로 어떻게 연결되는지 다이어그램을 통해 살펴보는 시간이다.

 

다이어그램들을 보며 설명을 들으면 아주 이해가 쏙쏙 된다.

 

강의자료에 있는 다이어그램을 여기에 복붙해오는 것은 양심에 찔리므로,

다이어그램이 보고 싶을 땐 강의자료를 열어 살펴보기로 하고

여기에는 그렇게 다이어그램을 보며 복습을 할 때 필요한 내용을 간단하게 적어둬야겠다.

 

 

 

 

회원 도메인 협력 관계

익숙한 그림이다.

 

클라이언트는 회원 서비스에 의존한다.

(입문 강의에서 배웠듯이, 서비스는 비즈니스 관점에서 필요한 기능을 정의한 클래스라는 것을 잊지 말자!)

회원 서비스는 회원가입, 회원조회 기능을 가지고 있다.

 

이 회원 서비스가 작동하려면 데이터 저장소가 필요하다.

우리는 하나의 데이터 저장소 인터페이스를 만들고,

세 가지의 데이터 저장소 구현체를 사용할 것이다.

그 세 가지는

1. 메모리 회원 저장소 (내 PC의 저장공간을 사용하는 방식. 프로그램이 종료되면 데이터는 휘발된다)

2. DB 회원 저장소 (휘발되지 않는 제대로 된 DB)

3. 외부 시스템 회원 저장소

이다.

 

초기 개발과 테스트에는 1번을 사용하다가 실제로는 2번과 3번을 사용한다. 갈아끼우는 것이다.

요구사항에서, 자체 DB를 사용할 수도 있고 외부 DB에 연결할 수도 있다고 했는데, 여기서 자체 DB란 2번을 가리키고 외부 DB란 3번을 가리킨다.

 

 

 

 

 

회원 클래스 다이어그램

이것도 입문 강의를 들었다면 쉽게 이해할 수 있는 다이어그램이다.

 

입문 강의에서 들은 내용은 이렇다.

리포지토리는 기술적 관점에서 프로그램이 가져야 할 기능들을 정의하고

서비스는 리포지토리에 만들어져있는 기능들을 가져와, 비즈니스적 관점에 부합하는 기능으로 가공한다.

 

이를 기억하고 다이어그램을 살펴보자.

 

MemberService 인터페이스가 있고,

그것을 바탕으로 구현이 된 구현체가 있다.

 

그 구현체는 MemberRepository 인터페이스에 의존한다.

이 MemberRepository를 바탕으로 구현된 구현체가 두 가지 그려져있다.

하나는 위의 도메인 협력관계에서 말한 세 가지 데이터 저장소 중 1번에 해당하는 MemoryMemberRepository

다른 하나는 제대로 된 DB를 다루는 DbMemberRepository이다.

 

 

 

 

회원 객체 다이어그램

회원 클래스 다이어그램이 클래스 간의 의존 관계를 그렸다면,

이 다이어그램은

실제 프로그램이 동작할 때 만들어져서 일을 할 객체들이 서로 어떤 참조 관계를 가지는지 그린 다이어그램이다.

 

따라서 이 다이어그램에 그려진 놈들은 모두 구체적인 구현체의 객체이다.

 

 

 

 

세 다이어그램의 역할

세 가지 다이어그램은 개발 과정에서 각자 다른 목적을 위해 쓰인다.

 

먼저 첫 번째인 도메인 협력 관계는 기획자들도 함께 볼 수 있는 다이어그램이다.

하긴 요구사항에 다 나와있는 것을 그림으로 바꾸기만 한 수준이므로 기획자들과 소통할 때 쓰기 좋을 것 같다.

고객이 이렇게 요구했으니 우리는 이렇게 설계할 거다 라는 매우 기본적인 표현방식으로 보인다.

 

두 번째인 클래스 다이어그램은 도메인 협력 관계를 바탕으로 개발자가 좀 더 세세하게 짜는 것이다.

 

세 번째인 객체 다이어그램은 클래스 다이어그램에서 보여주지 못하는 부분을 그린 것이다.

그 부분이 무엇이냐 하면,

실제 프로그램이 실행될 때에 작동할 객체들끼리의 명확한 참조 관계이다.

프로젝트에 포함된 모든 구현체가 클래스 다이어그램에 표시된다.

그런데 그 중 정확히 어떤 놈이 사용될지는, (우리가 어떻게 설정하느냐에 따르겠지만) 프로그램을 실행할 때! 동적으로 결정된다. 그래서 어떤 인스턴스가 사용될지를 클래스 다이어그램에서 확인하기는 어렵다.

이 점을 보완해주는 것이 객체 다이어그램이다.