Service계층의 의존

개발을 하다보면 늘 걸리는 것이 있다.

Service계층이 Repository를 의존하고 있는 것은 좋다.

그렇다면 Service계층이 다른 Service계층을 의존하는 것은 괜찮을까?

 

이를 허용하게되면 그 시간대의 개발관점에서 이보다 편한 것은 없다.   

그러나 이를 허용하면 안되는 이유 몇가지를 정리해보았다.

 

 

1. 트랜젝션의 원자성

 

객체지향적인 관점에서도 중요하지만 별개로 서비스 계층에서 하는 가장 큰 것 중 하나는 트랜잭션 원자성이라고 생각한다.
R이 아닌 CUD의 명령형 트랜잭션의 경우... DB의 일관성이 깨질 수 있기 때문에 서비스 운영상에 치명적인 해를 입힐 수 있다.
서비스가 다른 서비스를 알거나 할 때는 이 @transactional 처리를 할 때 코드를 추적하기 다소 어려울 수 있다. 되도록 하나의 서비스 계층을 갖거나... 순환 참조 등의 일을 피하여 계층형으로 (다른 서비스를 아우르는 서비스 계층을 하나 둠) 두면 좋을 것 같다.

 

2. 역할의 모호성

Repository를 의존하게 되면 Repository에서 가져온 다른 도메인들을 쉽게 사용할 수 있음.
따라서 가벼운 어플리케이션을 만든다면 그냥 Service가 다른 도메인의 Repository를 의존하여 사용하는 것이 오히려 더 개발하는데 용이하다고 생각함.

 

다만 어플리케이션의 규모가 커질수록 도메인도 커지고 도메인을 관리하는 Service도 많아짐. 이때 하나의 도메인 Service가 다양한 Repository를 관리하게 된다면 도메인 Service의 책임이 너무 무거워짐. 또한 해당 도메인을 관리하는 Service가 다른 도메인도 관리하게 되어 Service의 역할도 모호해짐.

 

따라서 하나의 Service가 하나의 Repository를 갖게하여 도메인을 관리하도록 하고 이들을 관리하는 상위 계층의 Service를 두어 트랜잭션관리를 하는 것을 생각하게 되었음.
순환 참조의 경우 순환 참조를 하게되는 상황자체를 막도록 리팩터링하는 것이 더 중요하며 순환참조를 사전에 확인하기 위해서 생성자 참조를 사용하는 이유도 있기 때문에 순환 참조가 발생하는 상황자체를 우려하지 않아도 된다고 생각함.