클린 아키텍처 도서 요약 내용입니다.

30장 데이터베이스는 세부사항이다.

아키텍처 관점에서 데이터베이스는 엔티티가 아니다. 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다. 소프트웨어 시스템의 아키텍처와 데이터베이스의 관계를 건물로 비교하면 건물의 아키텍처와 문 손잡이의 관계와 같다.

데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티다. 아키텍처 관점에서 보면 이러한 유틸리티는 저수준의 세부사항(매커니즘)일 뿐이라서 아키텍처와는 관련이 없다.

관계형 데이터베이스

관계형 데이터베이스의 기술이 얼마나 뛰어나든, 유용하든, 아니면 수학적으로 견고하든, 결국은 그저 기술일 뿐이다. 그리고 이는 관계형 데이터베이스가 세부사항임을 뜻한다.

관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에는 편리하지만, 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다. 애플리케이션 유스케이스는 이러한 방식을 알아서는 안되며 관여해서도 안된다. 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다.

많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다. 이렇게 하면 유스케이스, 업무 규칙, 심지어 UI조차도 관계형 데이터 구조에 결합되어 버린다.

데이터베이스 시스템은 왜 이렇게 널리 사용되는가?

오라클, MySQL, SQL 서버가 우위를 차지할 수 있던 이유는 무엇일까? 한마디로 답하자면, 바로 '디스크'때문이었다.

디스크때문에 피해갈 수 없는 시간 지연이라는 점을 완화하기 위해 색인, 캐시, 쿼리 계획 최적화가 필요해졌다.

디스크가 없다면 어떻게 될까?

세부사항

데이터베이스는 그저 메커니즘에 불과하며, 디스크 표면과 RAM 사이에서 데이터를 이리저리 옮길 때 사용할 뿐이다.

하지만 성능은?

성능은 아키텍처와 관련된 관심사가 아닌가? 당연히 아키텍처적인 관심사다. 하지만 데이터 저장소의 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사다. 데이터 저장소에서 데이터를 빠르게 넣고 뺄수 있어야 하는 것이 맞지만, 이는 저수준의 관심사다. 이 관심사는 저수준의 데이터 접근 메커니즘 단에서 다룰 수 있다.