프레임워크는 세부사항이다

32. 프레임워크는 세부사항이다

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

프레임워크 제작자

프레임워크는 당신이 풀어야 할 특별한 관심사를 염두에 두지 않는다.

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

혼인 관계의 비대칭성

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

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

프레임워크 제작자는 결합되기를 바란다.

프레임워크 제작자는 당신에게 프레임워크와 혼인하기를 요구

위험 요인

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

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

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

• 프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것이다.

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

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

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

해결책

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

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

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

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

스프링에서 @autowired가 업무 객체 도처에 산재해서는 안 된다.

이제 선언합니다

C++에서 STL을 피할 수 없다.

애플리케이션이 프레임워크와 결혼하고자 한다면 애플리케이션의 남은 생애 동안 그 프레임워크와 항상 함께 해야 한다.

결론

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

참조

1. 클린 아키텍처(Clean Architecture)