[Clean Architecture] 21장. 소리치는 아키텍처

Introduction Link to heading

  • 우리들의 애플리케이션 아키텍처는 뭐라고 소리치는가?
  • 상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스 파일을 볼 때 이 아키텍처가 어떤 아키텍처인지 바로 알 수 있는가? 아니면 프레임워크를 외치는가?

아키텍처의 테마 Link to heading

  • 이바 야콥슨의 Object Oriented Software Engineering: Use Case Driven Approach
  • 소프트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조라고 지적
  • 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 함
  • 아키텍처는 프레임워크에 대한 것이 아님
    • 그리고 절대로 그래서도 안됨
  • 아키텍처를 프레임워크로부터 제공받아서는 절대 안 됨
    • 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아님
  • 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없음

아키텍처의 목적 Link to heading

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

하지만 웹은? Link to heading

  • 웹은 아키텍처일까?
  • 웹은 전달 매커니즘이며, 애플리케이션 아키텍처에서도 그와 같이 다뤄야 함
  • 애플리케이션이 웹을 통해 전달된다는 사실은 세부사항이며, 시스템 구조를 지배해서는 절대 안됨
  • 실제 애플리케이션을 웹으로 전달할지 여부는 미루어야 할 결정사항 중 하나
  • 시스템 아키텍처는 시스템이 어떻게 전달될지에 대해 가능하다면 아무것도 몰라야 함

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

  • 프레임워크는 매우 강력하고 상당히 유용할 수 있고, “프레임워크가 모든 것을 하게 하자” 라는 태도를 취할 수 있지만, 이는 우리가 취하고 싶은 태도가 아니다
  • 프레임워크를 면밀하고 비판적으로 바라보고 판단하자
  • 프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라

테스트하기 쉬운 아키텍처 Link to heading

  • 아키텍처가 유스케이스를 최우선으로 한다면, 그리고 프레임워크와는 적당한 거리를 둔다면, 프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 함
  • 테스트를 돌리는데 웹 서버가 반드시 필요한 상황이 되어서는 안 됨
  • 데이터베이스가 반드시 연결되어 있어야만 테스트를 돌릴 수 있어서도 안 됨
  • 유스케이스 객체가 엔티티 객체를 조작해야 함
  • 최종적으로, 프레임워크로 인한 어려움을 겪지 않고도 반드시 이 모두를 있는 그대로 테스트할 수 있어야 함

결론 Link to heading

  • 아키텍처는 시스템을 이야기해야 함
  • 시스템에 적용한 프레임워크에 대해 이야기해서는 안 됨
  • 새로 합류한 프로그래머는 시스템이 어떻게 전달될지 알지 못한 상태에서도 시스템의 모든 유스케이스를 이해할 수 있어야 함