프레임워크 제작자

이들은 당신이 풀어야 할 특별한 관심사를 염두에 두지 않는다. 프레임워크 제작자는 당신을 알지 못하며, 당신이 풀어야 할 문제도 알지 못하기 때문이다.

물론 당신의 문제는 프레임워크가 풀려는 문제와 꽤 많이 겹칠 것이다. 겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해진다.

혼인 관계의 비대칭성

당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다. 당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다.

프레임워크 제작자는 당신의 애플리케이션이 가능하면 프레임워크에 공고하게 결합될 것을 강하게 역설한다.

프레임워크 제작자 입장에서는 프레임워크와의 이러한 결합이 위험 요소가 되지 않는다. 오히려 프레임워크와 결합되기를 바란다. 왜냐하면 제작자는 그 프레임워크에 대해 절대적인 제어권을 쥐고 있기 때문이다.

제작자는 당신도 자신의 프레임워크에 결합되기를 바란다. 한번 결합하면 그 관계를 깨기가 매우 어렵기 때문이다. 사용자가 많아지는 일은 자신의 프레임워크가 효과적임을 검증하는 최고의 방법이다.

사실상 프레임워크 제작자는 당신에게 프레임워크와 혼인하기를 요구하는 것이다. 하지만 프레임워크 제작자는 어떠한 경우에도 그에 상응하는 헌신을 당신에게 하지는 않을 것이다. 모든 위험과 부담은 오롯이 당신이 감수할 뿐, 제작자가 감수하는 건 아무것도 없다.

프레임워크의 아키텍처는 그다지 깔끔하지 않은 경우가 많다.
프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것이다. 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
프레임워크는 당신에게 도움되지 않는 방향으로 진화할 수도 있다.
새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.

프레임워크를 사용할 수는 있다. 하지만 프레임워크와 결합해서는 안 된다. 프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하라

업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면, 거절하라! 대신 프락시를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프락시를 위치시켜라

프레임워크가 핵심 코드 안으로 들어오지 못하게 하라. 대신 핵심 코드에 플러그인할 수 있는 컴포넌트에 프레임워크를 통합하고, 의존성 규칙을 준수하라.

예를 들어 당신은 스프링을 좋아할 것이다. 스프링은 훌륭한 의존성 주입 프레임워크다. 하지만, 업무 객체는 절대로 스프링에 대해 알아서는 안 된다.

업무 객체보다는 메인 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 낫다. 메인은 아키텍처 내에서 가장 지저분한, 최저 수준의 컴포넌트이기 때문에 스프링을 알아도 상관 없다.

정말로 결혼해야만 하는 프레임워크도 존재한다. 예를들어서 C++를 사용하고 있다면 STL과 결혼해야 할 가능성이 높다. 자바를 사용한다면 표준 라이브러리와 반드시 결혼해야 한다.

이러한 관계는 정상이다. 하지만 선택적이어야 한다. 다른 모든 것을 저버릴 때도 프레임워크를 사용해야 할 것이다.

가급적이면 프레임워크를 가능한 오랫동안 아키텍처 경계 너머에 두자.