4. 팬레터 서비스 정리, 팬레터 리포지토리 설계

팬레터 리포지토리에 어떤 메소드들이 필요한지 설계해보자.

 

서비스부터 생각해보는 것이 편하고 효율적일 것 같으니 서비스부터 생각해보려 한다. 그 후에 그 서비스를 구현하는 데 필요한 리포지토리를 뽑아낼 것이다.

 

팬레터 서비스 정리

 

 

팬레터 데이터와 관련된 띄움의 서비스는 무엇이 있을까?

 

팬 서비스

1. 팬은 새로운 팬레터를 작성할 수 있다.
2. 팬은 자신이 작성한 팬레터들을 한 번에 조회할 수 있다.
3. 팬은 자신이 작성한 팬레터들을 수신인별로 나누어 각각의 대화창에서 조회할 수 있다.
4. 팬은 자신이 작성한 팬레터들을 제목 기준으로 검색하여 조회할 수 있다.
5. 팬은 자신이 작성한 팬레터에 수신인이 좋아요를 남겼는지 여부를 확인할 수 있다.
6. 팬은 자신이 작성한 팬레터들을 삭제할 수 있다.

 

창작자 서비스

1. 창작자는 다른 창작자를 위한 새로운 팬레터를 작성할 수 있다.
2. 창작자는 자신에게 온 팬레터들을 한 번에 조회할 수 있다.
3. 창작자는 자신에게 온 팬레터들을 발신인별로 나누어 각각의 대화창에서 조회할 수 있다.
4. 창작자는 자신에게 온 팬레터들을 제목 기준으로 검색하여 조회할 수 있다.
5. 창작자는 자신에게 온 팬레터들에 좋아요를 누를 수 있다.
6. 창작자는 자신에게 온 후원금의 총 금액을 확인할 수 있다.

 

 

창작자가 팬레터를 읽었는지 여부를 기록하는 기능은, 읽었는지 여부를 자동 감지하는 기능을 구현한 후에 추가할 생각이다. 지금은 사용자의 클릭을 통해 on/off 되는 좋아요 기능만 구현하려 한다.

 

창작자가 각각의 팬레터에 남기는 답장 관련 작업은 답장 데이터를 따로 구축한 후에 해줄 것이다.

 

 

팬레터 리포지토리 설계

위의 서비스 정리를 기반으로 팬레터 리포지토리에 들어가야 할 메소드들을 정리해보면 다음과 같다.

 

1. 새 팬레터를 DB에 저장하는 메소드: 리턴 값은 void, 받는 값은 새 팬레터 객체
2. 특정 팬레터의 ID를 기준으로 DB를 탐색하는 메소드: 리턴 값은 팬레터 객체, 받는 값은 팬레터 ID
3. 발신인을 기준으로 DB를 탐색하는 메소드: 리턴 값은 Optional로 감싼 팬레터 리스트, 받는 값은 발신인아이디 String
4. 수신인을 기준으로 DB를 탐색하는 메소드: 리턴 값은 Optional로 감싼 팬레터 리스트, 받는 값은 수신인아이디 String
5. 제목과 발신인을 기준으로 DB를 탐색하는 메소드: 리턴 값은 Optional로 감싼 팬레터 리스트, 받는 값은 제목 String과 발신인 String
6. 제목과 수신인을 기준으로 DB를 탐색하는 메소드: 리턴 값은 Optional로 감싼 팬레터 리스트, 받는 값은 제목 String과 발신인 String
7. 특정 팬레터의 좋아요 여부를 변경하는 메소드: 리턴 값은 void, 받는 값은 팬레터 ID
8. 특정 팬레터를 DB에서 삭제하는 메소드: 리턴 값은 void, 받는 값은 팬레터 ID

 

창작자가 자신에게 온 후원금의 총 금액을 확인하는 기능은 4번 메소드를 실행시켜 Optional 리스트 내의 모든 팬레터 객체의 donation 값을 더하는 서비스 메소드로 완성할 것이다.

 

리턴 값이 void인 리포지토리 메소드들의 리턴 값을 boolean으로 바꿀지 고민 중이다. 해당 메소드가 제대로 실행되었다면 true를, 그렇지 않았다면 false를 리턴하는 방식을 써보면 오류 핸들링이 쉽지 않을까 하는 생각이 들기 때문이다.

하지만 일단은 void를 리턴하도록 코드를 짜고, 오류 핸들링은 메소드 자신의 내부에서 자체적으로 하도록 하겠다.

 

다음 게시글에서는 팬레터 리포지토리 인터페이스를 작성한다.