05 세부사항 (2)

31장. 웹은 세부사항이다

끝없이 반복하는 추

IT 역사는 모든 연산 능력을 중앙 서버에 두는 방식과 단말에 두는 방식을 사이에서 반복되는 진동을 겪어왔다.

웹도 이러한 진동 중 하나에 불과하다. (서버 팜 - 브라우저 애플릿 - Ajax/자바스크립트 - Node.js)

이 진동은 그저 핵심 업무 규칙의 중심에서 밀어내고 싶은 단기적인 문제일 뿐이다.

요약

GUI는 세부사항이다. 웹은 GUI다. 따라서 웹은 세부사항이다.

업무 로직은 다수의 유스케이스로 구성되며, 각 유스케이스는 사용자를 대신해서 일부 함수를 수행한다

각 유스케이스는 입력 데이터, 수행할 처리 과정, 출력 데이터로 이뤄진다.

완전한 입력 데이터와 그에 따른 출력 데이터는 데이터 구조로 만들어서 유스케이스를 실행하는 처리 과정의 입력 값과 출력 값으로 사용할 수 있다.

이렇게하면 각 유스케이스가 장치 독립적인 방식으로 UI라는 입출력 장치를 동작시킨다고 간주할 수 있다.

---

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

프레임워크 제작자

프레임워크 제작자는 당신이 풀어야 할 문제를 알 지 못한다.

혼인 관계의 비대칭성

프레임워크 제작자는 당신과 당신의 애플리케이션이 프레임워크에 공고하게 결합되기를 바란다.

그리고 한번 결합하면 그 관계를 깨기는 매우 어렵다. 이로인해 발생하는 모든 위험과 부담은 당신의 몫이며, 제작자가 감수하는 것은 아무것도 없다.

위험요인

앞서 말한 위험요인은 무엇인가?

• 프레임워크는 의존성 규칙을 위반하는 경향이 있다. 업무 객체를 만들 때, 프레임워크 제작자는 자신의 코드를 상속할 것을 요구한다.
• 프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 되지만, 제품이 성숙해지면 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
• 프레임워크는 당신에게 도움되지 않는 방향으로 진화할 수도 있다.
• 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.

해결책

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

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

프레임워크의 기반 클래스로부터 파생되야한다면 proxy로 구현해야하며, 핵심 코드에 플러그인 할 수 있는 컴포넌트에 프레임워크를 통합시켜야 한다.

예를들어 스프링 프레임워크를 사용할 때, @autowired 어노테이션이 업무 객체에 산재하도록 두지 않고 main 컴포넌트에서 사용하도록 해야한다.