소리치는 아키텍처

건물의 청사진을 살펴보고 있다고 해보자. 아키텍트가 문서를 작성했고 건물에 대한 일련의 계획을 보여주고 있다.

계획서가 주택을 그리고 있다면 정문, 거실로 연결되는 현관, 부엌 등을 볼 수 있을 것이다. 도서관이라면 커다란 정문, 사서를 위한 공간, 독서 공간 등이 있을 것이다.

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

아키텍처의 테마

이바 야콥슨(Ivar Jacobson)은 소프트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조라고 지적했다. 주택이나 도서관의 계획서가 해당 건축물의 유스케이스에 대해 소리치는 것처럼, 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 한다.

아키텍처는 프레임워크에 대한 것이 아니다. 아키텍처를 프레임워크로부터 제공받아서는 절대 안 된다. 프레임워크는 사용하는 도구일 뿐, 아키테겇가 준수해야 할 대상이 아니다.

아키텍처의 목적

좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에 프레임워크나 도구, 환경에 구애받지 않고 유스케이스를 지원하는 구조를 기술할 수 있다.

아키텍트가 주목하는 첫 번째 관심사는 주택이 거주하기에 적합한 공간임을 확실히 하는 것이지, 벽돌로 지어지는지를 확인하는 것이 아니다.

좋은 소프트웨어 아키텍처는 프레임워크, DB, 웹 서버 그리고 여타 개발 환경이나 도구에 대한 결정을 미룰 수 있게 해준다. 좋은 아키텍처는 유스케이스에 중심을 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.

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

눈이 아플 정도로 면밀하게 프레임워크를 살펴보자. 그리고 비판적인 태도를 취하자. 프레임워크를 어떻게 사용할지, 사용하지 않으려면 어떻게 해야할지를 스스로 물어보라.

어떻게 하면 아키텍처를 유스케이스에 중점을 둔 채 그대로 보존할 수 있을지를 생각하라. 프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.

테스트하기 쉬운 아키텍처

프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.

엔티티는 반드시 오래된 방식의 간단한 객체(plain old object)여야 하며, 프레임워크나 DB 등 복잡한 것에 의존해서는 안 된다. 유스케이스 객체가 엔티티 객체를 조작해야 한다.

결론

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