DB/SQL중심으로 시스템을 설계하는 아키텍처를 데이터 중심 아키텍처라고 한다.
데이터 중심 아키텍처의 특징은 하나의 업무 트랜잭션에 모든 계층으 코드가 종속되는 경향이 있다는 거다.
예를들어 사용자의 이름을 검색하는 기능을 구현할때
모든계층(프레젠테이션, 서비스, 데이터엑세스(DAO))가 이 기능에 맞춰서 만들어진다.
사용자 이름을 검색하는 SQL또는 저장 프로시저로 작성하고 SQL결과를 1대1로 매핑하여 MAP에 담고 그대로 화면에 보여준다.
서비스계층은 별로 할 일이 없다.
화면, 어플리케이션, DB의 3티어 어플리케이션이지만
어플리케이션은 화면과 DB를 연결해주는 단순한 인터페이스 역할을 전락해버리고
자바의 오브젝트는 단지 HTTP 서비스 채널을 만들어 주고 DB 연결 기능을 제공하는것으로 역할이 축소 되었다.
실질적으로 2티어 어플리케이션과 같은 느낌이다.
이런 식의 개발은 자바 기술이 발전하기 이전의 엔터프라이즈 시스템에서 흔히 발견할 수 있다.
필자가 지금까지 경험해본 공공기관SI 뿐만 아니라 대기업 시스템에서도 이런 아키텍처가 대부분이였다.
심지어 DB 저장 프로시저에 HTML을 문자열로 저장하여 관리하던 시스템도 있었다.
그렇다면 왜 이런 데이터중심 (DB/SQL중심의 로직 구현) 아키텍처를 사용할까?
이런 방식의 개발은 개발이 쉽다는 장점이 있다. 적어도 처음에는 그렇다.
대부분의 개발자는 복잡한 로직은 SQL로 작성하는 것에 익숙하고
SQL로 화면에 보여질 결과(반올림, 형식 포맷, 숫자 계산) 까지 작성하고 화면에서는 그냥 보여주기만 하면 됬다.
또한 지금처럼 배포 자동화의 기능을 활발이 사용하지 않을때,
서버 보안등의 이슈로 인해 소스 배포하기 어려울때
자바 코드를 수정하여 컴파일하여 배포하고 톰캣을 재기동 할 필요 없이
SQL, 프로시저는 스크립트만 수정하여 실행하는것으로 비즈니스 로직을 수정할 수 있다.
또한 업무에 따라 SQL을 짜기 때문에 개발자들끼리 서로 간섭없이 할당된 업무(기능)을 독립적으로 만드는 데도 편하고
최소환의 공통 모듈만 제공되는 것을 사용하며 업무별, 기능별 화면을 구현했다.
하지만 이러한 개발 방식은 각 계층의 코드가 긴밀하게 연결되어있어 객체지향의 장점을 별로 활용되지 못했다.
그러므로 변화에 매우 취약하고, 중복을 제거하기도 쉽지 않다.
또한 필드 하나가 달라저도 비슷한 DAO메서드를 새로 만들기도 하며,
DB와 SQL, 저장 프로시저가 많아질수록 점점 확장성이 떨어졌다.
DB는 확장에 한계가 있을뿐만 아니라 확장하는데도 큰 비용이 들기 때문이다.
상대적으로 어플리케이션의 비용은 적게 들고 서버를 쉽게 늘려 확장할 수도 있다.
또한 SQL, 프로시저로 담긴 로직은 테스트하기 힘들지만 어플리케이션에 담긴 로직은 간단히 검증 할 수 있다.
목데이터를 사용하여 DB에는 부하를 가능한 주지 않으며 테스트 할 수도 있다.
또한 개발자 개개인의 실력, 코딩 습관에 따라 비슷한 로직이라도 다른 코드가 나올 수 있다.
또한 비슷한 기능을 개발자에 따라 2번 구현되는 경우도 있다.
그런데도 이런 설계를 사용하는 회사가 굉장히 많다.
데이터 중심 아키텍처는 잘 작성된 SQL하나가 수백줄의 자바 코드를 대신 할 수 있다.
그러나 과연 이게 바람직할까??
물론 그렇다고 객체지향설계가 다 좋다는 것은 아니다.
개발 능력이 떨어지는 경우 자바 코드로 구현한 비즈니스 로직이 복잡한 SQL보다 더 이해하기 힘들 수도 있고
또한 개발진행중 비즈니스 로직이나 요구사항수정, 설계가 변경되어 수정이 필요한 경우에 수정이 쉽지 않을 수 있다.
테스트 케이스를 잘 작성해서 TDD를 잘하면 좋겠지만
그렇지 않다면 오히려 SQL,프로시저 보다 더 다루기 힘든 스파케티 코드로 전락할 위험도 있다.
