프레임워크 제작자
- 프레임워크 제작자는 자신이 해결해야 할 고유한 문제나 자신의 동료와 친구들의 문제를 알고 있다. 그리고 그러한 문제를 해결하기 위해 프레임워크를 만든다. 당신의 문제를 해결하기 위해서가 아니다
- 당신의 문제가 프레임워크가 풀려는 문제와 겹치는 영역이 클수록 프레임워크는 실제로 더 유용해진다.
혼인 관계의 비대칭성
당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다. 당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다.
위험 요인
- 프레임워크의 아키텍처는 그다지 깔끔하지 않은 경우가 많다. 프레임워크 제작자는 자신의 프레임워크가 당신의 가장 안쪽 원과 결합되기를 원한다. 하지만 프레임워크가 한 번 안으로 들어가버리면 다시는 원 밖으로 나오지 않을 것이다. 결혼반지는 이미 당신의 손가락에 끼워졌고, 다시는 빼지 못할 것이다.
- 프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것이다. 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
- 프레임워크는 당신에게 도움이 되지 않는 방향으로 진화할 수도 있다. 도움도 되지 않는 신규 버전으로 업그레이드하느라 다른 일을 못할 수도 있다.
- 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.
해결책
프레임워크와 결혼하지 말라
- 프레임워크를 사용할 수는 있지만 적당히 거리를 두어야 한다. 프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하라. 프레임워크가 아키텍처의 안쪽 원으로 들어오지 못하게 하라
- 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면, 거절하라. 대신 프록시를 만들고 업무규칙에 플러그인 할 수 있는 컴포넌트에 이들 프락시를 위치시켜라.
- 예를 들어 스프링에서 @Autowired 어노테이션이 업무 객체 도처에 산재해서는 안 된다. 업무 객체는 절대로 스프링을 알아서는 안된다.