21. 소리치는 아키텍처

도서관의 아키텍처를 보고 있다고 가정하자. 커다란 정문, 체크인과 체크아웃을 담당할 사서를 위한 공간, 독서 공간.. 이를 보면 이 아키텍처는 "도서관이야"라고 소리칠 것이다.

여러분의 애플리케이션 아키텍처는 뭐라고 소리치는가? 상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스파일을 볼 때, 이 아키텍처는 "헬스 케어 시스템이야"또는 "재고 관리 시스템이야"라고 소리치는가?아니면 "레일스야, 스프링이야, ASP야!" 라고 소리치는가?

아키텍처의 테마

• 주택이나 도서관의 계획서가 해당 건축물의 유스 케이스에 대해 소리치는 것처럼, 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스 케이스에 대해 소리쳐야 한다.
• 아키텍처는 프레임워크에 대핳ㄴ 것이 아니다. (절대로 그래서도 안된다.)
• 아키텍처를 프레임워크로부터 제공받아서는 절대 안 된다.
• 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아니다.
• 아키텍처를 프레임워크 중심으로 만들어버리면 유스 케이스가 중심이 되는 아키텍처는 절대 나올 수 없다.

아키텍처의 목적

• 좋은 아키텍처는 유스 케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스 케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다.
• 좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹서버 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다.
  • 프레임워크는 열어 둬야 할 선택사항이다.
• 좋은 아키텍처는 유스 케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.

하지만 웹은?

• 웹은 아키텍처일까? 아니다.
• 웹은 전달 메커니즘(입출력장치)이며, 애플리케이션 아키텍처에서도 그와 같이 다뤄야 한다.
• 애플리케이션이 웹을 통해 전달된다는 사실은 세부사항이며, 시스템 구조를 지배해서는 절대 안 된다.

프레임워크는 도구일 뿐, 삶의 방식이 아니다.

• 프레임워크 제작자들은 흔히 모든 것을 아우르는, "프레임워크가 모든 것을 하게 하자"라는 태도를 취한다.
  • 이는 우리가 취하고 싶은 태도가 아니다.
• 프레임워크를 사용하지 않으려면 어떻게 해야 할지를 스스로에게 묻고 어떻게 하면 아키텍처를 유스 케이스에 중점을 둔 채 그대로 보존할 수 있을지 생각하라
• 프레임워크가 아키텍처 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.

테스트하기 쉬운 아키텍처

• 아키텍처가 유스 케이스를 최우선으로 한다면, 그리고 프레임워크와는 적당한 거리를 둔다면, 프레임워크를 전혀 준비하지 않더라도 필요한 유스 케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.
• 테스트를 돌리는데 웹 서버가 반드시 필요한 상황이 되어서는 안 된다.
• 엔티티 객체는 반드시 오래된 방식의 간단한 객체여야 하며, 프레임워크나 데이터베이스, 또는 여타 복잡한 것들에 의존해서는 안 된다.
• 유스 케이스 객체가 엔티티 객체를 조작해야 한다.
• 최종적으로 프레임워크로 인한 어려움을 겪지 않고도 반드시 이 모두를 있는 그대로 테스트할 수 있어야 한다.

결론

• 아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안 된다.