[Clean Architecture] 32장. 프레임워크는 세부사항이다
|
Introduction
- 프레임워크는 상당히 인기를 끌고 있음
- 일반적으로 말하자면 좋은 현상
- 무료인 데다 강력하며 유용한 프레임워크가 많음
- 하지만 아무리 해도 프레임워크는 아키텍처가 될 수 없음
프레임워크 제작자
- 프레임워크 제작자는 우리를 알지 못하며, 우리가 풀어야 할 문제도 알지 못함
- 프레임워크 제작자는 본인의 문제, 혹은 동료와 친구들의 문제를 해결하기 위해 만들 뿐이며, 이 문제가 많이 겹칠 수록 인기를 끌 것
- 겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해짐
혼인 관계의 비대칭성
- 우리와 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적
- 우리는 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 우리를 위해 아무런 헌신도 하지 않음
- 프레임워크 제작자는 프레임워크에 대해 장기간에 걸친 막대한 헌신을 요청하지만, 어떠한 경우에도 그에 상응하는 헌신을 해주지는 않음
- 이 혼인 관계는 일방적
- 모든 위험과 부담은 오롯이 당신이 감수할 뿐, 제작자가 감수하는 건 아무 것도 없음
위험 요인
- 프레임워크의 아키텍처는 그다지 깔끔하지 않은 경우가 많음
- 프레임워크는 의존성 규칙을 위반하는 경향이 있음
- 프레임워크는 애플리케이션 추기 기능을 만드는 데는 도움이 될 것
- 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것
- 프레임워크는 우리에게 도움이 되지 않는 방향으로 진화할 수도 있음
- 도움이 되지 않는 신규 버전으로 업그레이드하느라 다른 일을 못할 수도 있음
- 심지어 사용 중이던 기능이 사라지거나 반영하기 힘든 형태로 변경될 수도 있음
- 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있음
해결책
프레임워크와 결혼하지 말라!
- 프레임워크를 사용할 수는 있지만, 결합해서는 안 됨
- 프록시를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프록시를 위치시켜라
- 프레임워크가 핵심 코드 안으로 들어오지 못하게 하라
- 스프링의 경우
- 업무 객체는 절대로 스프링에 대해 알아서는 안됨
- 업무 객체보다는 메인 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 나음
- 메인은 아키텍처 내에서 가장 지저분한, 최저 수준의 컴포넌트이기 때문에 스프링을 알아도 상관 없음
이제 선언합니다
- 정말로 결혼해야만 하는 프레임워크도 존재
- C++ <-> STL
- 자바 <-> 표준 라이브러리
- 이러한 관계는 정상, 하지만 선택적이어야 함
- 프레임워크와 결혼은 결코 가볍게 시작할 수 있는 관계가 아님
결론
- 프레임워크와의 첫 만남부터 바로 결혼하려 들지 말라