웹 애플리케이션을 개발하면서 객체지향적인 설계 방식을 적용한다는 것이 생각만큼그리 만만한 일은 아니다. 특히 문제가 되는 부분이 바로 모델링된 객체와 데이터베이스 간의 맵핑을 처리하는 부분일 것이다.OOP와 관계형 데이터베이스 간에 일치하지 않는 부분(mismatch)이 존재하는 것이 그 첫째 이유겠지만, 개발자들에게익숙해져 버린 기존의 습관 때문에 발생하는 문제도 무시할 수는 없는 듯하다. 데이터베이스를 따로 모델링하고 ASP나 JSP,PHP 등의 스크립트 언어로 절차적인 방식으로 프로그래밍하던 시절의 그 "유혹적인 습관"을 떨쳐 버리기가 쉽지 않기 때문이다.

물론 반드시 이런 방식이 나쁘다고 말하는 것은 아니다. ASP나 PHP 등에 비해 어떤 것이 더 우수하다고 주장하는 건 더더욱아니다. 다만, 개발환경에 따라 그리고 사용하는 도구가 무엇이냐에 따라 개발 방법도 달라져야 함을 말하는 것이다. 예를 들면,레일스는 순수 객체지향 언어인 루비를 기반으로 한다. 또한 MVC 아키텍처 패턴을 따르고 액티브레코드라는 걸출한 ORM 도구도제공한다. 따라서 레일스로 웹 애플리케이션을 개발하는 경우에는 기존에 각종 웹 스크립트 언어들을 사용하여 페이지 단위로 개발하던것과는 다른 방식을 적용하는 것이 오히려 생산성을 높이고 프레임워크의 장점을 제대로 살릴 수 있는 방법이 된다.

조금 오래된 책이기는 하지만 마틴 파울러의 책 "엔터프라이즈 애플리케이션 아키텍처 패턴"에서는 엔터프라이즈 애플리케이션을 프리젠테이션, 비즈니스로직, 그리고 데이터소스의 3개 레이어(layer)로 나누고 다시비즈니스로직 레이어에서 사용하는 패턴으로 트랜잭션 스크립트 패턴, 테이블 모듈 패턴, 그리고 도메인 모델 패턴이라는 3개의패턴을 제시하고 있다. 그리고 이들 각각의 비즈니스 레이어 패턴들은 해당 패턴과 잘 어울리는 데이터소스 패턴이 존재한다. 예를들어, 마이크로소프트의 DNA나 .NET 기반으로 프로그래밍 하는 경우는 비즈니스 로직에서 레코드셋(recordset)이라는테이블 모듈 패턴을 사용하기 때문에 데이터소스 층에서는 테이블 데이터 게이트웨이 패턴이 잘 어울리는 것과 같은 식이다.

그렇다면 레일스의 경우는 어떨까? 레일스는 ORM 도구로 액티브레코드를 사용한다. 그리고 이 액티브레코드는 다름아닌 파울러의데이터소스 패턴 중 하나인 액티브레코드를 충실하게 구현한 것이다. 액티브레코드 패턴은 아주 복잡하지는 않은 도메인 모델에서모델과 데이터베이스 테이블이 잘 맵핑되는 경우에 적합한 패턴이라고 되어 있다. 결국 바꿔 말하면 레일스에서 액티브레코드를 제대로사용하려면 비즈니스 로직 부분에서는 도메인 모델 패턴을 따라야 한다는 말이 된다. OOAD에서 말하는 제대로 된 도메인 모델링을해야 한다는 말이다. 요는 "선 데이터모델링 후 도메인모델링"이 아니라 "선 도메인모델링 후 데이터맵핑"이 되야 한다는 것이다.

물론 이게 언제나 가능한 것은 아닐 것이다. 경우에 따라서는 레거시 데이터베이스가 이미 존재하고 있어서 어쩔 수 없이 이를 사용해야하는 경우도 있고, 또 조직이나 역할 분담 등 여러 가지 이유로 인해 데이터베이스 스키마에 대한 변경 자체가 불가한 경우에는어쩔 수 없이 다른 방법을 사용하는 일도 생길 수 있다. 그렇지만 그런 경우가 아닌, 애플리케이션을 새로 개발하고 데이터베이스의스키마까지도 맘대로(?) 다룰 수 있는 경우라면 우선 도메인 모델링부터 충실히 하는 것이 옳은 수순이 아닐까.