[책 정리] 32. 프레임워크는 세부사항이다. - Clean Architecture

-

유용한 프레임워크가 많다. 하지만 프레임워크는 아키텍처가 될 수 없다.

 

 

 

프레임워크 제작자

 

-

프레임워크가 풀려는 문제와 당신의 문제는 꽤 많이 겹칠 것이다.

겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해진다.

 

 

 

혼인 관계의 비대칭성

 

-

당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다.

당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다.

 

 

-

대게의 경우 프레임워크 제작자는 프레임워크를 어떻게 통합할 수 있을지 조언한다.

이들은 프레임워크를 중심에 두고 우리의 아키텍처는 그 바깥을 감싸야 한다고 말한다.

또한 이들은 프레임워크의 기반 클래스에서 직접 파생하거나, 프레임워크의 기능들을 업무 객체에 바로 임포트(import)해서 사용하라고 권한다.

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

 

프레임워크 제작자 입장에서는 프레임워크와의 이러한 결합이 위험 요소가 되지 않는다.

오히려 결합되기를 바란다. 제작자는 그 프레임워크에 대해 절대적인 제어권을 쥐고 있기 때문이다.

프레임워크와 절대로 분리할 수 없는 방식으로 쓰는 사용자가 많아지는 일은 자신의 프레임워크가 효과적임을 검증하는 최고의 방법이다.

 

 

 

위험 요인

 

-

프레임워크 아키텍처는 그다지 깔끔하지 않은 경우가 많다.

프레임워크는 의존성 규칙을 위반하는 경향이 있다.

업무 객체를 만들 때, 프레임워크 제작자는 자신의 코드를 상속할 것을 요구한다.

당신만의 고유한 엔티티를 만들 때 말이다.

프레임워크 제작자는 자신의 프레임워크가 당신의 가장 안쪽 원과 결합 되기를 바란다.

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

 

 

-

프레임워크는 앱의 초기 기능을 만드는 데는 도움이 될 것이다.

하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.

 

 

-

프레임워크는 당신에게 도움이 되지 않는 방향으로 진화할 수도 있다.

도움도 되지 않는 신규 버전으로 업그레이드하느라 다른 일을 못할 수도 있다.

심지어 사용 중이던 기능이 사라지거나 반영하기 힘든 형태로 변경될 수도 있다.

 

 

-

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

 

 

 

해결책

 

-

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

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

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

프레임워크가 아키텍처의 안쪽 원으로 들어오지 못하게 하라.

 

업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면 거절하라!

대신 프락시(proxy)를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프락시를 위치시켜라.

프레임워크가 핵심 코드 안으로 들어오지 못하게 하라.

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

 

 

 

이제 선언합니다.

 

-

정말로 결혼해야만 하는 프레임워크도 존재한다.

예를 들어 C++ 를 사용하고 있다면 STL 과 결혼해야 할 가능성이 높다.

자바를 사용한다면 표준 라이브러리와 반드시 결혼해야 한다.

이 관계들은 피하기 힘들다. 그리고 이러한 관계는 정상이다.

 

 

-

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

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

 

 

 

결론

 

-

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

결혼 서약에 앞서 잠시 동안 연애를 할 수 있는 방법이 있는지 확인하라.

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

 

끝