[Clean Architecture] 데이터베이스/웹/프레임워크는 세부사항이다.

이번 포스팅은 이 책에서 앞서 설명했던 내용을 더 구체적으로 설명하는 챕터 입니다. 어떠한 서비스를 구현하기 위해 어떠한 유즈케이스가 필요합니다. 하지만 그 유즈케이스에서 어떤 데이터베이스를 사용해야 하는지, 어떤 웹서버를 사용해야 하는지, 어떤 프레임워크를 사용해야 하는지는 아키텍처 관점에서 중요한 사항이 아닙니다. 이것들을 세부사항이라고 합니다.

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

데이터베이스는 말 그대로 데이터를 저장하는 공간입니다. 데이터를 그냥 저장하는것이 아닌, 쿼리를 통해 빠르게 데이터를 수정, 읽기, 삭제할 수 있도록 하는 소프트웨어 입니다. 이것의 형태가 어떻게 되든, 아키텍처의 관점에서는 그리 중요한 사항이 아닙니다. 즉, 단순히 데이터를 장기적으로 저장하는 공간에 지나지 않는 것입니다. 따라서 아키텍처 관점에서 본다면 회전식 자기 디스크에 데이터가 있기만 한다면, 데이터가 어떤 형태인지는 절대로 신경 써서는 안됩니다. (물론 성능도 아키텍처 관점에서 중요한 요소이지만 이는 저수준의 단계에서 다루어야 합니다.)

웹은 세부사항이다.

1960년대 웹이 등장하면서 엄청난 충격을 주었습니다. 기존의 클라이언트-서버 아키텍처는 거의 사장당할 수준이었습니다. 하지만, 사실 웹이 바꾼건 아무것도 없었습니다. 웹 역시 세부사항입니다.

웹이 등장하고 연산능력을 서버에 모두 두어야 한다, 아니다 클라이언트에 두어야 한다 로 진동이 있었습니다. 아직도 이 진동은 계속 울리고 있고, 이처럼 앞으로도 우리는 연산 능력을 어디에 둬야할지 알 수 없을 것입니다.

아키텍트는 이런 상황을 대처할 수 있도록 멀리 볼 수 있어야 합니다. 모든 상황에 대처하기는 어렵겠지만, 이렇게 자주 변경되는 요소들에 대해 추상레벨을 높여 겨길 시키는 것은 충분히 가능합니다.

예를들어 GUI만 변경하면 다른 기능들은 동작하도록 구성하는 것이 좋은 아키텍트라는 것입니다.

프레임워크는 세부사항이다.

우리가 사용하는 대다수의 프레임워크는 어떤 서비스를 만들때의 공통의 문제를 해결하기 위해 등장하였습니다. Spring Boot, Unity, Android Native 같은 프레임워크가 그런 것이죠.

하지만 프레임워크의 문서를 읽게되면, 만들고자 하는 서비스와 프레임워크가 아주 강하게 결합하도록 설명되어 있습니다. 프레임워크 제작자의 입장에서는 고객이 만들고자 하는 서비스의 구체적인 내용은 세부사항이기에 문제가 되지 않지만, 서비스를 만드는 사람들의 입장에서는 의존관계가 반대가 되어 문제가 발생할 수 있습니다. 다음과 같은 문제들이 있습니다.

• 프레임워크는 의존성 규칙을 위반하는 경향이 있다. 업무 객체를 만들 때, 프레임워크 제작자는 자신의 코드를 상속할 것을 요구한다. 당신만의 고유한 엔티티를 만들 때 말이다.
• 프레임워크는 애플리케이션의 초기 기능을 만드는데는 도움이 될 것이다. 하지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될것이다. 시간이 지나면서 프레임워크와 싸우고 있는 자신을 발견하게 될것이다.
• 프레임워크는 당신에게 도움이 되지 않는 방향으로 진화할 수 있다.
• 새롭게 나온 프레임워크로 갈아타고 싶을수도 있다.

이러한 문제를 해결하기 위해서는 프레임워크와 적당한 거리를 둬야 합니다. 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면 거절해야 합니다. 대신 프락시를 만들고 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프락시를 위치시켜야 합니다. 프레임워크가 핵심 코드 안으로 들어오는것을 계속 경계해야 합니다.

물론 프레임워크를 사용하면서 프레임워크에 대한 거리를 완전히 두는것은 불가능 하지만, 프레임워크를 사용하면서 거리를 둘 수 있는 방향을 계속 고민하며 설계해야 합니다.

Clean Architecture 카테고리 내 다른 글 보러가기