21장 - 소리치는 아키텍처

소리치는 아키텍처

건물의 청사진을 보고 그 계획서가 한 가족이 거주할 주택을 그리고 있다면 아키텍처는 집이라고 소리칠 것입니다.

만약 도서관의 아키텍처를 보고 있고 여러 가지 도서관에 필요한 구성을 보다면 아키텍처는 도서관이라고 소리칠 것입니다.

 

우리의 애플리케이션을 보고는 아키텍처는 뭐라고 소리칠까요?

 

상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스 파일을 볼 때 "헬스 케어 시스템이야", "재고 관리 시스템이야"라고 소리칠까요?

 

아니면 "스프링/하이버네티트야", "레일스야"라고 소리치는가요?

 

 

주택이나 도서관의 계획서가 해당 건축물의 유스케이스에 대해 소리치는 것처럼, 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 합니다.

 

아키텍처의 목적

책에서 여러번 언급하는 내용입니다.

 

좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만들어야 합니다.

 

유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시켜야 합니다.

 

테스트하기 쉬운 아키텍처

만약 아키텍처가 유스케이스를 최우선으로 하며 프레임워크와 적당한 거리를 둔다면 프레임워크 없이도 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 합니다.

 

테스트를 위해 웹이 반드시 필요해야 하며, 데이터베이스가 반드시 연결되어 있어야만 테스트를 돌릴 수 있어서도 안됩니다.

 

 

결론

아키텍처는 시스템에 대해 이야기해야 합니다.

절대로 시스템에 적용한 프레임워크에 대해서는 이야기해서는 안됩니다.

 

새로 합류한 프로그래머가 시스템을 보았을 때 유스케이스에 대해 이해할 수 있어야 하며, 이 시스템이 어떤 시스템인지를 알 수 있어야 합니다.