Library > Core > Unit

논리적인 Architecture 를 설계하기 위한 Module

• Unit

Service 와 동일한 기능을 하는 Annotation

• Description

Service 와 동일한 기능을 하는 Annotation 을 구현한 이유는 비즈니스 로직과 데이터 로직을 분리하기 위해서 제작했다.
예를 들어 Entity 하나의 등록 기능을 Service 세 곳에서 사용하고 있다고 가정해보자.
그리고 각 Service 의 작업자가 다르다고 가정해보자.
같은 기능을 구현하더라도 스타일이 다를 수 있다. 어떤 작업자는 수행 로직에서 Repository 를 사용해서 기능을 구현할 수도 있고,
어떤 작업자는 Service 에 등록 기능을 Method 로 만들어서 구현할 수도 있고,
어떤 작업자는 다른 작업자의 기능을 사용하기 위해 다른 작업자의 Service 를 주입받을 수도 있다.
이러한 상황에서 다른 작업자의 작업물을 수정해야하는 상황이 닥쳤을 때 자신과 다른 스타일에 분석에 시간이 걸린다.
극단적인 예시라고 생각하겠지만 작업자가 많아질수록 위와 같은 상황을 자주 마주쳤다.
그래서 위 상황을 하나로 통일하고자 Unit 이라는 개념을 생각했다.

처음에는 생각했다고 생각했고, 오히려 중간 과정을 하나 추가해서 작업자가 헷갈릴 수 있다고 판단해서 제거할까 생각했다.
하지만 다른 솔루션에서 Unit 과 같은 구조를 사용하는 것을 보고 나서는 이 고민을 하는 사람이 더 있다고 알게되어 용기를 얻게 되었다.

Unit 이라는 구조를 사용한 이유는 다음과 같다.

• 수행 로직에서 Repository 를 직접 사용하는 방법은 직관적일 수 있으나 수정이 발생했을 때 Repository 를 사용한 모든 로직을 검토해야하기 때문에 제외시켰다.
• Service 에 Method 로 구현하는 방법은 수행 로직에 Repository 를 직접 사용한 것과 같이 수정이 발생하는 경우 Repository 를 사용하는 모든 Service 를 검토해야 한다.
• 기능이 있는 Service 를 주입받는 방식은 주입받는 Service 가 많아질수록 사용하는 기능이 많아질수록 혼란을 야기할 수 있다.

위와 같은 이유로 두 개의 룰을 만들었다.

1. Repository 는 Unit 에서만 주입받을 수 있다.
2. Service 는 서로 주입받을 수 없다.

같은 구조를 사용하는 솔루션에서는 위 두 가지 룰이 Validation 으로 들어가 있었다.
그래서 룰을 어기고 작성하게 되면 오류라고 가이드를 해줬다.
이 Unit 은 강제성은 없지만 위 룰을 따라 작업을 하고 있다.

내가 제작한 Unit 은 아직 강제성은 없다.
처음에는 룰이 어긋나면 compile 시점에 오류를 발생시킬까 고민도 해봤지만,
너무 강제하면 생각이 굳어지게 된다.
지금 제작한 구조가 정답이라고 생각하지 않는다.
그리고 새로운 기술들을 적용할 때마다 상황은 변화한다.
같이 작업하는 다른 작업자가 의문이나 새로운 아이디어를 떠올렸다면 논의를 통해서 방향을 정하는 것이 나에게도 더 좋은 일이라고 생각한다.
그래서 강제성은 없다.