아무리 해도 프레임워크는 아키텍처가 될 수 없다.

프레임워크 제작자

프레임워크 제작자는 자신이 해결해야 할 고유한 문제를 위해 프레임워크를 제작한 것 이므로, 내가 풀려는 문제와 완벽하게 일치할수는 없다.

혼인 관계의 비대칭성

프레임워크 제작자와 사용자의 관계는 놀라울 정도로 비대칭 적이며 프레임워크 제작자는 당신에게 프레임워크와 혼인하기를 요구하는 것 처럼 보인다.

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

이러한 결합은 제작자에게는 위험 요소가 되지 않으며, 프레임워크에대해 절대적인 제어권을 쥐고 있는 입장에서 오히려 프레임워크와 결합되기를 바란다.

한술 더 떠 제작자는 사용자도 프레임워크에 결합되어 관계를 깨지 못하는 것을 기대하고 있다.

제작자는 프레임워크에대해 장시간에 걸친 헌신을 요청하지만, 그에 상응하는 헌신을 받을수 는 없을 것이다.

모든 위험과 부담은 당신이 감수할 뿐, 제작자가 감수하는 건 아무것도 없다.

위험요인

프레임워크의 아키텍처는 깔끔하지 않은 경우가 많다.
프레임워크는 의존성 규칙을 위반하는 경향이 있다.

• 업무 객체를 만들 때 프레임워크 코드를 상속할 것을 요구한다.
• 고유한 엔티티에 코드가 상속되면 애플리케이션의 가장 안쪽 원과 프레임워크의 결합이 발생한다.

프레임워크가 한번 원 안으로 들어가버리면 다시는 원 밖으로 나오지 않을 것이다.

결국 싸우게된다.

프레임워크가 애플리케이션의 초기 기능을 만드는데 도움이 될 것이지만, 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.

앞으로의 변화

프레임워크는 애플리케이션에게 도움되지 않는 방향으로 진화할 수도 있다.

더 나은 프레임워크

새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.

해결책

프레임워크와 결혼하지 말라!

프레임워크를 사용할 수는 있지만 결합해서는 안된다.

프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급해야한다.

업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면, 프락시를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이 프락시를 위치시켜 프레임워크가 핵심 코드 안으로 들어오지 못하게 해야한다.

대신 핵심 코드에 플러그인할 수 있는 컴포넌트에 프레임워크를 통합하고, 의존성 규칙을 준수한다.

이제 선언합니다.

애플리케이션이 프레임워크와 결혼하고자 한다면 애플리케이션의 남은 생애 동안 그 프레임워크와 항상 함께 해야 한다는 사실을 반드시 명심해야한다.

결코 가볍게 시작할 수 있는 관계가 아니다.

결론

프레임워크와의 첫 만남부터 바로 결혼하려 들지 말라.

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