‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
아키텍처의 테마
- 주택이나 도서관의 계획서가 해당 건축물의 유스케이스에 대해 소리치는 것처럼, 소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 한다.
- 아키텍처를 프레임워크로부터 제공받아선 절대 안된다.
- 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야할 대상이 아니다.
- 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스 중심이 되는 아키텍처가 절대 나올 수 없다.
아키텍처의 목적
- 좋은 아키텍처는 유스케이스를 그 중심에 두므로, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무 문제 없이 기술할 수 있다.
- 좋은 소프트웨어 아키텍처는 프레임워크, DB, 웹서버, 그리고 여타 개발 환경 문제나 도구에 대해선 결정을 미룰 수 있도록 만든다.
- 프레임워크, 웹 서버 등은 열어 둬야할 선택사항이다.
- 좋은 아키텍처는 프로젝트의 훨씬 후반까지 레일스, 스프링, 하이버네이트, 톰캣, MySQL 에 대한 결정을 하지 않아도 되도록 해준다.
- 뿐만 아니라 이러한 결정을 쉽게 번복할 수 있도록한다.
- 좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.
하지만 웹은?
- 웹은 전달 메커니즘(입출력 장치)이며, 애플리케이션 아키텍처에서도 그와 같이 다뤄야 한다.
- 애플리케이션이 웹을 통해 전달된다는 사실은 세부사항이며, 시스템 구조를 지배해선 절대 안된다.
- 그리고 이는 미뤄야할 결정사항 중 하나이다.
시스템 아키텍처는 시스템이 어떻게 전달될지에 대해 가능하다면 아무것도 몰라야 한다. 과도한 문제를 일으키거나 근본적인 아키텍처를 뜯어고치지 않더라도 시스템을 콘솔 앱, 웹, 앱 등으로 전달할 수 있어야 한다.
프레임워크는 도구일 뿐, 삶의 방식이 아니다.
- 어떻게 하면 아키텍처를 유스케이스에 중점을 둔채 그대로 보존할 수 있을지를 생각하라.
- 프레임워크가 아키텍처 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.
테스트하기 쉬운 아키텍처
- 아키텍처가 유스케이스를 최우선으로 하고 프레임워크와는 적당한 거리를 둔다면, 프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.
- 테스트를 돌리기 위해 웹서버, DB 가 반드시 필요한 상황이 되선 안된다.
- 엔티티 객체는 반드시 오래된 방식의 간단한 객체(plain old object)여야 하며, 프레임워크나 DB, 또는 여타 복잡한 것들에 의존해선 안된다.
- 유스케이스 객체가 엔티티 객체를 조작해야 한다.
- 최종적으로, 프레임워크로 인한 어려움을 겪지 않고도 반드시 이 모두를 있는 그대로 테스트 가능해야 한다.
결론
- 아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해선 안된다.
- 당신이 헬스 케어 시스템을 구축한다면 새로 들어온 팀원이 소스 저장소를 봤을때 첫 인상은 “오 헬스 케어 시스템이군” 이어야만 한다.
- 새로 합류한 팀원은 시스템이 어떻게 전달될지를 알지 못한 상태에서 시스템의 모든 유스케이스를 이해할 수 있어야 한다.
- 언제가 이들은 이렇게 물을 것이다. “모델처럼 보이는 것들을 확인했습니다. 그런데 뷰와 컨트롤러는 어디에 있죠?”
- 그러면 다음과 같이 답해야만 한다. “아, 그것은 세부사항이므로 당장은 고려할 필요가 없습니다. 나중에 결정할 겁니다.”