clean-architecture-book-thumbnail

한 가족이 거주할 주택의 아키텍처를 보면 이 아키텍처는 "집이야"라고 소리칠 것이다.

도서관의 아키텍처를 보고 있다면 이 아키텍처는 "도서관이야"라고 소리칠 것이다.

여러분의 애플리케이션 아키텍처는 뭐라고 소리치는가?

상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스 파일을 볼 때, 이 아키텍처는 "기숙사 관리 시스템이야" 또는 "재고 관리 시스템이야"라고 소리치는가?

아니면 "레일스(Rails)야", "스프링(Spring)/하이버네이트(Hibernate)야", 아니면 "ASP야"라고 소리치는가?

Table of Contents

아키텍처의 테마

  • 이바 야콥슨(ivar Jacobson)이 소프트웨어 아키텍처에 대해 쓴 독창적인 저서인 《Object Oriented Software Engineering》을 읽어보자.

    • 이 책의 부제가 유스케이스 주도 접근법(Use Case Driven Approach)이라는 점을 주목하자.
    • 야콥슨은 소프트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조라고 지적했다.
  • 아키텍처는 프레임워크에 대한 것이 아니다(그리고 절대로 그래서는 안 된다).

    • 아키텍처를 프레임워크로부터 제공받아서는 절대 안 된다.
    • 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아니다.
    • 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다.

아키텍처의 목적

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

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

좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합을 분리시킨다.

하지만 웹은?

웹은 아키텍처인가? → 아니다.

시스템이 웹을 통해 전달된다는 사실이 시스템의 아키텍처에 영향을 주는가? → 아니다.

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

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

프레임워크는 매우 강력하고 상당히 유용하다. 다만, 비판적으로 보자.

  • 비용이 얼마나 드는가?
  • 어떻게 사용할지, 사용하지 않으려면 어떻게 해야하는가?

어떻게 하면 유스케이스에 중점을 둔 채 그대로 보존할 수 있는지를 생각하라.

  • 프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.

테스트하기 쉬운 아키텍처

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

결론

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

References

  • 모든 출처는 Clean Architecture 도서에 있습니다.