1회차 진행으로 책의 내용을 거의 그대로 따라치는 중이며 요약 정리는 2회차부터 진행할 예정
아키텍처 관점에서 데이터베이스는 엔티티가 아니다.
즉 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다. 소프트웨어 시스템의 아키텍처와 데이터베이스의 관계를 건물로 비교하면 건물의 아키텍처와 문 손잡이의 관계와 같다. 중요하지 않다고 하는게 아니다. 데이터베이스는 애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요하다. 하지만 데이터베이스는 데이터 모델이 아니다.
데이터베이스는 일개 소프트웨어일 뿐이다. 데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티다. 아키텍처 관점에서 이러한 유틸리티는 저수준의 세부사항(메커니즘)일 뿐이기에 아키텍처와는 관련이 없다. 그리고 뛰어난 아키텍트라면 저수준의 메커니즘이 시스템 아키텍처를 오염시키는 일을 용납하지 않는다.
에드거 커드가 1970년에 정의한 관계형 데이터베이스 원칙은 지속적으로 성장했고, 1980년대 중반이되어 데이터 저장소의 주류 형태가 되었다.
하지만, 이 모델이 데이터를 저장하고 접근하는데 있어 얼마나 뛰어나건간게 결국 기술일 뿐이다.
그리고 이는 관계형 데이터베이스가 세부사항임을 의미한다.
관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에는 편리하지만, 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 중요하지 않다. 애플리케이션의 유스케이스는 이런 방식을 알 필요도 관여해서도 안된다. 데이터가 테이블 구조를 가진다는 사실은 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다.
많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기 돌아다니도록 허용했는데, 이는 잘못된 아키텍처 설계로 유스케이스, 업무 규칙, UI조차도 관계형 데이터 구조에 결합되어 버린다.