6부. 세부사항1
30장. 데이터베이스는 세부사항이다
아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아닌 세부사항이다.
아키텍처와 데이터베이스의 관계 : 건물의 구조와 손잡이
데이터베이스는
데이터 모델이 아닌 일개 소프트웨어
데이터에 접근할 방법을 제공하는 유틸리티
아키텍처 관점에서 보면 데이터베이스는 저수준의 세부사항(매커니즘) 일 뿐이므로 관련이 없다.
→ 뛰어난 아키텍트 : 저수준의 매커니즘이 시스템 아키텍처를 오염시키도록 하지 않는다.
관계형 데이터베이스
관계형 데이터베이스는 데이터를 저장하고 접근하는데 탁월한 기술이다.
하지만 결국은 그저 기술일 뿐, 세부사항이다.
데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다.
→ 테이블과 행이 객체 형태로 시스템에 돌아다닌다면 아키텍처적으로 잘못된 설계
데이터베이스 시스템은 왜 이렇게 널리 사용되는가?
데이터베이스 시스템 (오라클, MySQL 등) 이 소프트웨어 시스템과 기업을 장악할 수 있었던 이유는 ‘디스크’ 때문이다.
디스크 : 지난 반세기동안 사용된 데이터 저장소의 중심
디스크의 단점은 느리다는 것이다. → 색인, 캐시, 쿼리 계획 최적화, 데이터를 표현하는 일종의 표준적인 방식 필요해짐
데이터 접근 및 관리 시스템
파일 시스템
문서 기반
문서 이름을 기준으로 저장 및 조회는 잘 동작하지만, 내용을 기준으로는 크게 도움되지 않음.
관계형 데이터베이스 관리 시스템 (RDBMS)
내용을 기반으로 레코드를 자연스럽고 편리하게 찾는 방버 제공
정형화되지 않은 문서를 저장하고 검색하는데 부적합
디스크가 없다면 어떻게 될까?
디스크는 RAM으로 대체되고 있다.
모든 데이터가 RAM에 저장된다면 데이터를 어떻게 체계화할 것인가?
→ 연결 리스트, 트리 등의 데이터 구조로 체계화하여, 데이터에 접근할 때는 포인터나 참조 사용
(당신은 이미 이렇게 일하고 있을것이다)
세부사항
데이터베이스는 디스크 표면과 RAM 사이에서 데이터를 옮길 때 사용되는 메커니즘에 불과하다.
데이터를 장기적으로 저장하는 공간에 지나지 않는다.
아키텍처 관점에서 본다면, 데이터가 어떤 형태인지, 디스크 자체가 존재한다는 사실조차도 인식해선 안된다.
성능
데이터 저장소의 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사이다.
즉, 성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다. (저수준의 관심사)
결론
체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요하다. 데이터는 중요하다. 데이터베이스는 세부사항이다.
31장. 웹은 세부사항이다
1960년대 이래로 ‘모든 연산 능력을 중앙 서버에 두는 방식’ 과 ‘모든 연산 능력을 단말에 두는 방식’ 사이에서 끊임없이 움직여왔다.
웹이 이러한 상황에서 바꾼 것은 아무것도 없다.
모든 연산 능력을 서버 팜에 위치 → 브라우저에 애플릿 추가 → 동적인 내용 다시 서버로 이동 → 웹 2.0 + Ajax와 자바스크립트를 이용해 처리 과정의 많은 부분을 브라우저로 다시 이동 → Node.js를 이용해 자바스크립트를 다시 서버로 이동
끝없이 반복하는 추
앞으로도 우리는 연산능력을 어디에 둘지 알 수 없을 것이다.
아키텍트로서 우리는 멀리 내다봐야한다. 이 진동은 그저 업무 규칙의 중심에서 밀어내고 싶은 단기적인 문제일 뿐이다.
요약
GUI는 세부사항이며, 웹은 GUI이다. 따라서 웹은 세부사항이다.
아키텍트라면 이러한 세부사항을 핵심 업무 로직에서 분리된 경계 바깥에 두어야 한다.
UI와 어플리케이션 사이에는 추상화가 가능한 또 다른 경계가 존재한다.
업무 로직은 다수의 유스케이스로 구성, 유스케이스는 사용자를 대신해서 일부 함수를 수행
유스케이스는 입력 데이터, 수행할 처리 과정, 출력 데이터를 기반으로 기술 가능
완전한 입력 데이터와 그에 따른 출력 데이터는 데이터 구조로 만들어서 유스케이스를 실행하는 처리 과정의 입력 값과 출력 값으로 사용할 수 있다.
→ 각 유스케이스가 장치 독립적인 방식으로 UI라는 입력 장치를 동작시킨다고 간주할 수 있다.
결론
이러한 종류의 추상화는 만들기 쉽지 않고, 제대로 만들려면 수차례의 반복 과정을 거쳐야 한다.
하지만 가능하다.
32장. 프레임워크는 세부사항이다.
프레임워크는 아키텍처가 될 수 없다.
프레임워크 제작자
프레임워크 제작자는 자신이 해결해야 할 고유한 문제나 자신의 동료와 친구들의 문제를 알고 있다. 그리고 그러한 문제들을 해결하기 위해 프레임워크를 만든다. 당신의 문제를 해결하기 위해서가 아니다.
혼인 관계의 비대칭성
당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다.
프레임워크를 사용하는 경우, 우리는 프레임워크 제작자가 제공하는 문서를 꼼꼼히 읽는다.
대개의 경우 이들은 프레임워크를 중심에 두고 우리의 아키텍처를 그 바깥에 감싸야 한다고 말한다.
프레임워크 제작자 입장에선, 당신의 애플리케이션과 프레임워크가 결합되기를 바란다.
사실상 당신에게 프레임워크와 혼인하기를 요구하는 것이다.
위험요인
프레임워크는 의존성 규칙을 위반하는 경향이 있다.
업무 객체를 만들 때, 프레임워크 제작자는 자신의 코드를 상속할 것을 요구한다.
프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것이다. 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
프레임워크는 당신에게 도움되지 않는 방향으로 진화할 수도 있다.
새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.
해결책
“프레임워크와 결혼하지 말라!”
프레임워크를 사용할 수는 있다. 다만 프레임워크와 결합해서는 안 된다. 적당히 거리를 두자.
프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하라. 프레임워크가 아키텍처의 안쪽 원으로 들어오지 못하게 하라.
정말 결혼해야만 하는 프레임워크도 존재한다. ( C++ 과 STL )
하지만 선택적이어야 한다. 애플리케이션이 프레임워크와 결혼하고자 한다면 애플리케이션의 남은 생애 동안 그 프레임워크와 항상 함께 해야 한다는 사실을 반드시 명심해야 한다.
결론
프레임워크와의 첫만남부터 바로 결혼하려 들지 말라. 가급적이면 프레임워크를 가능한 한 오랫동안 아키텍처 경계 너머에 두자.
Last updated