프레임워크는 상당한 인기를 끌고 있다. 일반적으로 말하자면 좋은 현상이다.
하지만 아무리 해도 프레임워크는 아키텍처가 될 수 없다.
대다수의 프레임워크 제작자는 커뮤니티에 도움이 되기를 바라는 마음에 자신의 작업물을 무료로 제공한다. 이들은 받은 것을 되돌려 주고 싶어 한다.
프레임워크 제작자는 자신이 해결해야 할 고유한 문제나 자신의 동료와 친구들의 문제를 알고 있다. 그리고 그러한 문제들을 해결하기 위해 프레임워크를 만든다. 당신의 문제를 해결하기 위해서가 아니다.
당신과 프레임워크 제작자와의 관계는 놀라울 정도로 비대칭적이다.
당신은 프레임워크를 위해 대단히 헌신해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다.
우리는 프레임워크 제작자가 제공하는 문서를 꼼꼼히 읽는다.
대개의 경우 이들은 프레임워크를 중심에 두고 우리의 아키텍처는 그 바깥을 감싸야 한다고 말한다.
또한 이들은 프레임워크의 기반 클래스에서 직접 파생하거나, 프레임워크의 기능들을 업무 객체에 바로 임포트해서 사용하라고 권한다.
프레임워크 제작자는 오히려 당신이 자신의 프레임워크에 결합되기를 바란다.
사실상 프레임워크 제작자는 당신에게 프레임워크와 혼인하기를 요구하는 것이다.
즉 프레임워크에 대해 장기간에 걸친 막대한 헌신을 요청하는 것이다.
이 혼인 관계는 일방적이다. 모든 위험과 부담은 오롯이 당신이 감수할 뿐, 제작자가 감수하는 건 아무것도 없다.
앞서 말한 위험 요인은 무엇인가? 당신이 고려해야 할 위험 요인들은 다음과 같다.
프레임워크의 아키텍처는 그다지 깔끔하지 않은 경우가 많다.
프레임워크 제작자는 자신의 코드를 상속할 것을 요구한다.
프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것이다. 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
프레임워크는 당신에게 도움되지 않는 방향으로 진화할 수도 있다. 도움도되지 않는 신규 버전으로 업그레이드하느라 다른 일을 못할 수도 있다.
새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.
해결책은 무엇인가?
프레임워크와 결혼하지 말라.
프레임워크와 결합해서는 안 된다. 적당히 거리를 두자. 프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하라.
업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면 거절하라. 대신 프락시를 만들고 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프락시를 위치시켜라.
프레임워크가 핵심 코드 안으로 들어오지 못하게 하라. 대신 핵심 코드에 플러그인할 수 있는 컴포넌트에 프레임워크를 통합하고, 의존성 규칙을 준수하라.
예를 들어 스프링은 훌륭한 의존성 주입 프레임워크인데, 의존성을 연결할 때 스프링의 오토와이어링기능을 사용할 것이다. @autowired 어노테이션이 업무 객체 도처에 산재해서는 안 된다. 업무 객체는 절대로 스프렝이 대해 알아서는 안 된다.
업무 객체보다는 메인 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 낫다.
메인은 아키텍처 내에서 가장 지저분한, 최저 수준의 컴포넌트이기 때문에 스프링을 알아도 상관 없다.
자바를 사용한다면 표준 라이브러리와 반드시 결혼해야 한다.
이러한 관계는 정상이다. 하지만 선택적이어야 한다. 애플리케이션이 프레임워크와 결혼하고자 한다면 애플리케이션의 남은 생애 동안 그 프레임워크와 항상 함께해야 한다는 사실을 반드시 명심해야 한다.
프레임워크와의 첫만남부터 바로 결혼하려 들지 말라. 결혼 서약에 앞서 잠시 동안 연애를 할 수 있는 방법이 있는지 확인하라. 가급적이면 프레임워크를 가능한 한 오랫동안 아키텍처 경계 너머에 두자. 아마 젖소를 사지 않고도 우유를 얻는 방법을 찾을 수 있을 것이다.