‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
30장 - 데이터베이스는 세부사항이다.
- 애플리케이션 내부 데이터 구조는 시스템 아키텍처에서 대단히 중요하다. 하지만 데이터베이스는 데이터 모델이 아니다.
- 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다. 그저 저수준의 세부사항이기 때문이다..
- 많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다. 이렇게하면 유스케이스, 업무 규칙, 심지어는 UI조차도 관계형 데이터 구조에 결합되어 버린다. (DAO를 통한 DTO 모델이 여기저기 돌아다니는구조..)
- 데이터베이스는 그저 데이텉를 회전식 자기 디스크 표면에서 이리저리 옮길 뿐인 기술이며 그저 세부사항일 뿐이다.
31장 - 웹은 세부사항이다.
- 웹은 GUI고 GUI는 세부사항이다. 고로 웹은 세부사항이다.
- 아키텍트라면 이러한 세부사항을 핵심 업무 로직에서 분리된 경계 바깥에 두어야 한다.
- 웹은 입출력 장치고 우리는 애플리케이션을 장치 독립적으로 만들어야 한다.
- UI와 애플리케이션 사이엔 추상화가 가능한 또 다른 경계가 존재한다. 업무 로직은 다수의 유스케이스로 구성되며, 각 유스케이스는 사용자를 대신해서 일부 함수를 수행하는것으로 볼 수 있다. 각 유스케이스는 입력 데이터, 수행할 처리 과정, 출력 데이터를 기반으로 기술할 수 있다.
- 완전한 입력 데이터와 그에 따른 출력 데이터는 데이터 구조로 만들어서 유스케이스를 실행하는 처리 과정의 입력값과 출력값으로 사용할 수 있다. 이방식을 따르면 각 유스케이스가 장치 독립적인 방식으로 UI라는 입출력 장치를 동작시킨다고 간주할 수 있다.
32장 - 프레임워크는 세부사항이다.
위험 요인
- 프레임워크는 의존성 규칙을 위반하는 경향을 비롯하여 그다지 깔끔하지 않은 경우가 많다. 프레임워크가 한번 안으로 들어가버리면(핵심 업무 로직) 다시는 원 밖으로 나오지 않을 것이다.
- 제품이 성숙해지면 프레임워크가 제공하는 기능 틀을 벗어나게 될 것이고 이 과정에서 프레임워크와 계속 싸우고있을것이다.
- 프레임워크는 도움됮지 않는 방향으로 진화할수도 있다.
- 새롭고 더 나은 프레임워크가 등장하여 갈아타고 싶을 수도 있다.
해결책
프레임워크와 결혼하지 말라!
- 프레임워크와는 사용할 수 있지만 결합되선 안되고 적당한 거리를 둬야한다.
- 프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하라. (아키텍처 안쪽 원으로 들어오지 못하게 하라.)
- 프레임워크가 핵심 코드 안으로 들어오지 못하게 하라. 핵심 코드에 플러그인 할 수 있는 컴포넌트에 프레임워크를 통하라고, 의존성 규칙을 준수하라.
- 스프링의
@Autowired어노테이션이 업무 객체 도처에 산재해선 안된다. 업무 객체는 절대로 스프링에 대해 알아선 안된다. - 업무 객체보단 메인(Main) 컴포넌트에서 스프링을 사용해서 의존성을 주입해주는 편이 낫다. 메인은 아키텍처 내에서 가장 지저분한, 최저 수준의 컴포넌트기 때문에 스프링을 알아도 상관없다.
결론
- 프레임워크와 처음부터 너무 강합게 결합하기보단 가급적 오랫동안 아키텍처 경계 너머에 두자. (핵심 업무 로직으로 부터 최대한 바깥쪽)