1. 문자 발송 서비스 설계 및 구현

이 포스팅은 인프런에 있는 김영한 강사님의 스프링 핵심 원리 강의를 들으며 개인 공부를 한 것입니다.
소스코드는 제가 직접 작성하였습니다. (참고 : 깃허브주소)

🎯 목표

1. 역할과 구현을 충실하게 분리하자
2. 다형성도 활용하고, 인터페이스와 구현 객체를 분리하자

✅ 비즈니스 요구사항과 설계

• 고객
  • 고객을 등록하고 조회할 수있다
  • 고객은 메시지를 받는 전체허용과 전체거부 두 가지 상태가 있다 (상태가 더 늘어날 수 있다)
  • 고객 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)
• 문자
  • 문자는 정보성문자, 광고성문자, 인증문자 세가지 문자 유형이 있다 (유형이 더 늘어날 수 있다)
  • 고객에게 문자를 발송할 수 있다
  • 문자를 발송할 수 있는 시간대가 정해져 있다 (8시 부터 ~ 20시 까지만 가능)
  • 고객의 메시지수신상태를 보고 발송유무를 필터링한다
  • 한 고객에게 광고성 문자는 하루에 2개만 발송할 수 있다 (나중에 변경될 수 있다)

✅ 고객 도메인 설계

고객 클래스를 만들까 말까 고민을 하였는데
김영한 강사님도 회원 엔티티는 예제 용도로 최소한의 기능만 넣어서 구현하셨다고 하셨다
나도 문자 발송 서비스를 구현하기 최소한의 기능만 고객 클래스를 설계하였다.

💬 고객 도메인 설계의 문제점

• 로컬개발용으로 MemoryCustRepository를 만들었으나
• MemoryCustRepository 에서 DbCustRepository로 변경할 때 OCP 원칙에 위반된다
• CustServiceImpl 의존관계가 인터페이스 뿐만 아니라 구현(MemoryCustRepository)까지 모두 의존하여 DIP 원칙에 위반된다
• CustServiceImpl 클라이언트가 구현클래스 MemoryCustRepository를 직접 선택한다

✅ 문자 도메인 설계

• 사실 더 구현하고 싶은 기능이 많았으나 어떻게 관계를 작성해야할지 감이 안잡혀서 주요 기능만 관계를 그렸다.
• 이때 발송필터링이라는 큰 역할안에 시간필터링, 고객*SMS동의필터링, 광고문자필터링이 다 들어가야한다.
  • 디자인패턴에 이렇게 쓸 수 있는 구조가 있었던 거 같은데... 찾아봐야겠다.
• 시간필터링은 테스트환경, 운영환경으로 나눠서 구현하면 유연하고 변경이 용이하게 할 수 있다.
• 고객*SMS동의필터링은 요구사항이 계속 변경될 가능성이 있다.
• 광고문자필터링 또한 요구사항이 계속 변경될 가능성이 있다.

💬 문자 도메인 설계의 문제점

• 필터링 부분의 역할과 구현을 충실하게 분리했는지 확신이 서지 않는다
• Repository를 어디까지 호출해야할지... 모르겠다... (뭐가 더 좋은 방법인지 모르겠다)
  • SmsService에서 SmsFilter를 호출하는데 둘 다 Repository를 호출한다
  • SmsFilter에서 Repository를 호출하지 않는 방법이 있을까?

SmsFilterImpl 클라이언트 코드에서

• custRepository가 필요한 이유는 고객SMS동의필터링시 고객Id로 고객SMS동의타입이 필요하기 때문이다
• smsRepository가 필요한 이유는 광고필터링시 한 고객에게 광고메시지가 몇 건 갔는지 내역조회를 해야한다.