Service 아키텍처 수정 2가지 제안 #109
Description
기능 설명
추가하고 싶은 기능에 대해 설명해주세요.
1. CQRS 방법
- 생각한 이유: getBoard, getMember 등 기본적인 정보를 조회하는 경우 각각의 여러 service에서 메서드를 여러번 private 으로 구현하게 되는데, 이런 코드를 재사용하여 유지보수를 편리하게 하는 것이 중요하다고 생각하고, 각 도메인에 맞는 로직만 해당 파일에 있는 것이 중요하다고 생각합니다. 따라서 조회 메서드와 변경 점이 생기는 메서드를 분리하여 조회의 경우 다양한 서비스에서 순환 참조 없이 구성할 수 있도록 구현을 제안합니다.
레퍼런스 https://azderica.github.io/02-architecture-msa/
2. Interface화
서비스 계층을 인터페이스로 분리하는 이유는 OCP(개방-폐쇄 원칙) 와 DIP(의존성 역전 원칙) 을 적용하여 코드의 유연성과 확장성을 확보하기 위함입니다.
이를 통해 클라이언트(Controller)는 구체적인 구현체가 아닌 추상화(Interface)에 의존하게 되어 결합도가 낮아지고 변경에 강한 구조를 가질 수 있습니다.
또한 인터페이스 기반 설계는 단위 테스트 시 Mock 객체 주입이 용이해져 테스트 코드의 작성성과 유지보수성이 향상됩니다.
이러한 구조는 다형성을 극대화하여 다양한 정책이나 구현체를 자유롭게 교체하고 확장할 수 있는 기반이 됩니다.
결국 이는 전략 패턴, 팩토리 패턴과 같은 객체지향 설계 원칙의 실현이자, 대규모 시스템에서 모듈화, 재사용성, 안정성을 확보하는 핵심 방법론입니다.
해결 방안
- 각 파트별로 Interface 도입 및 변경과 조회의 코드는 분리하여 구성하기