[10] 30~32 세부사항

23.10.29

[30] 데이터베이스는 세부사항이다

DB는 그저 매커니즘에 불과하며 디스크 표면과 RAM 사이에서 데이터를 이리저리 옮길 때 사용할 뿐이다. 실제로 비트를 담는 거대한 그릇이며, 데이터를 장기적으로 저장하는 공간에 지나지 않는다.

그러므로 세부사항인 DB 를 아키텍처 중심에 두어서는 안되며, 즉 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하면 안된다.

※ DB 가 널리 사용되는 이유

디스크에 있는 데이터를 접근하는 건 너무 느리기 때문에, 시간 지연을 완화하기 위해 색인, 캐시, 쿼리 계획 최적화 같은 것들이 필요해졌는데 그럴러면 원천 데이터가 있는 곳이 필요했다.

그래서 문서 기반의 파일 시스템, 내용 기반의 DB 시스템이 출현했다. 파일 시스템은 파일을 편리하게 저장하는 기능을 제공하고 DB 는 데이터를 편리하게 찾는 방법을 제공한다.

 

[31] 웹은 세부사항이다

웹 이전에는 모든 연산을 중앙 서버에 두는 서버-클라이언트 아키텍처였다가 Ajax와 JS 이용해 처리 연산을 브라우저에서 하는 웹 아키텍처로 이동했다. 그러다가 다시 노드를 이용해 다시 서버로 이동한다.

이런 GUI, 즉 웹 의 진동은 계속되니, 세부사항으로 치부하고 업무 규칙과 분리해야 한다. 마케팅의 귀재가 나타나 데스크탑 앱을 웹 브라우저로 변경해달라고 할지도 모른다.

 

[32] 프레임워크는 세부사항이다

프레임워크 개발자는 우리가 풀어야 할 특별한 관심사를 염두에 두지 않는다. 그리고 프레임워크 제작자 입장에서는 우리 코드와 프레임워크가 결합되는게 위험 요소가 되지 않는다. 왜냐하면 제작자는 그 프레임워크에 절대적인 제어권을 쥐고 있고, 분리할 수 없도록 사용하는 건 프레임워크가 효과적임을 검증하는 방법이기 때문이다.

프레임워크와 결합하면 위험 요소

• 의존성 규칙을 위반할 수 있다. 우리의 고유한 엔티티를 만들 때 프레임워크 코드를 상속할 것을 요구한다. 한 번 안쪽 원안으로 들어가면 결합돼서 밖으로 빼기 쉽지 않을 것이다.
  • 근데 프레임워크가 기능이 변화되거나 우리 코드에 도움이 되지 않는 방향으로 진화하면, 혹은 더 나은 프레임워크가 등장해서 갈아타고 싶어지면.. 수정할 게 너무 많아질 것이다.

해결책

프레임워크 소스를 아키텍처 바깥 쪽의 세부사항으로 취급하라. 상속받으라고 하면 프록시 객체를 만들고 업무 규칙에 플러그인할 수 있는 컴포넌트에 프록시를 넣어라.

ex. 스프링에서 @Autowired가 업무 규칙 객체에 산재해선 안 된다. 업무 규칙은 스프링에 대해 알아서는 안 된다. 대신 메인 컴포넌트에서 주입 받고 넘겨주어라.

 

레퍼런스

클린 아키텍처 30~32 장