s3와 tika 의존성 분리

@Service
class MemberServiceImpl @Autowired constructor(
    private val memberRepository: MemberRepository,
    private val passwordEncoder: PasswordEncoder,
    private val jwtTokenManager: JwtTokenManager,
    private val s3Service: S3Service,
    private val tikaService: TikaService
    )

개발을 하다 보니 핵심 도메인에 s3와 apache tika의 의존성이 너무 강결합이 되는 것이 보임.

이 방식이라면 S3와 TIKA의 변형에 다른 도메인들도 전파를 받을 환경이 되기에 리팩토링이 필요하다 생각.

솔루션

의존성 역전의 법칙을 통해 이를 해결하고자 함

의존성을 역전시키면 핵심 도메인 로직들은 외부서비스를 관리하는 추상화 타입을 의존하게 되기에 변형에 자유로워짐.

interface MediaService{
    fun upload(file: MultipartFile, filePath: String):String
    fun upload(fileList: List<MultipartFile>, filePath: String):List<String>
}

S3와 TIKA는 사실상 한 세트로, 검증과 업로드는 하나의 외부 도메인이 되기에 둘을 interface를 통해 하나로 묶음.

 

@Service
class MediaServiceImpl(
    private val s3Service: S3Service,
    private val tikaService: TikaService
): MediaService {
  override fun upload(file: MultipartFile, filePath: String):String {
        if (!tikaService.validateMediaFile(file)) {
            throw IllegalArgumentException("Invalid file format")
        }
        return s3Service.upload(file,filePath)
    }
  override fun upload(fileList: List<MultipartFile>, filePath: String):List<String> {
      if (!fileList.all { tikaService.validateMediaFile(it) }) {
          throw IllegalArgumentException("Invalid file format")
      }//하나라도 이상하면 전체 취소
      //없으면 전체 upload
      return fileList.map { s3Service.upload(it, filePath) }
  }
}

구현체에서 mediaService가 파일검증과 업로드라는 관심사를 전담하게 되어

핵심 도메인에선 mediaService가 하는 일을 모르게 하여 각 개체가 관심사에 집중할 수 있도록하였음.

 

최종플젝...바쁘다..!!!