DDD - ORM과 투명한 영속성 10부 11부

 

DDD 이터니티 조용호 님의 블로그를 보고 다시 한번 공부하기 위해서 정리하게 되었습니다!

 

---

 

 

애초에 아키텍처를 잡을 때 영속성을 고려했어야 했는데 아키텍처의 중요성을 뼈저리게 느끼게 되는 순간이다.

뭔가 망가지지 않았을까? 이럴 때 의지할 수 있는 건 단 하나밖에 없다. 회귀 테스트를 믿으라.

 

 

• 테스트를 실행하기 전에 한가지 더 알려 둘 것이 있다. 
• 가능하면 단위 테스트는 데이터베이스에 의존하지 않은 채로 실행할 수 있어야 한다. 
• 즉, 데이터베이스가 가동되지 않아도 각 클래스만을 고립시켜 테스트할 수 있도록 테스트 케이스를 작성해야 한다. 
• 정확하게 말하면 데이터베이스를 포함시키는 테스트는 단위 테스트가 아니라 통합 테스트이다.

 

 

• 데이터베이스와 연계해야 하는 통합 테스트에서 가장 어려운 문제는 테스트 데이터를 고립시키는 것이다. 
• 우선 개발자들이 사용하는 테스트 데이터들이 충돌하지 않아야 한다. 
• 만약 테스트 데이터가 서로 충돌하여 테스트가 실패한 경우 문제의 원인을 발견하기가 쉽지 않게 된다. 

 

 

• 두 번째 문제는 테스트 데이터들의 초기화와 정리 문제이다. 
• 테스트를 실행하기 위해서는 테스트에 필요한 테스트 데이터들이 데이터베이스에 입력되어 있어야 한다. 
• 테스트가 종료된 후에는 사용된 테스트 데이터들을 제거해야 한다. 
• 테스트가 종료된 후에도 테스트 데이터들이 그대로 존재할 경우 다음 테스트 결과에 영향을 미칠 수 있기 때문에 테스트를 고립시키라는 기본 원칙을 위배하게 된다.

 

 

• 앞의 문제를 해결할 수 있는 가장 좋은 방법은 개발자 별로 개발용 데이터베이스를 가지는 것이다.
• 즉, 자신만의 고립된 개발환경에 샌드 박스를 구성하고 개발을 진행하는 것이다.
• Hibernate와 같은 ORM을 사용하면 데이터베이스 간의 호환성 문제를 해결할 수 있기 때문에 본 아티클에서 사용하는 HSQLDB와 같은 가벼운 데이터베이스를 사용하여 개발자 환경에서 어플리케이션을 개발한 후 Oracle이나 Informix를 사용하는 개발 서버에서도 별다른 수정 없이 어플리케이션을 실행시키는 것이 가능하다. 
• 그러나 이것은 DBA에 의해 엄격하게 데이터베이스가 관리되는 프로젝트의 경우 적용하기가 쉽지 않다.

 

 

• 개발자들 간의 충돌을 막으면서도 테스트 데이터의 정리도 자동으로 수행하는 방법은 각 테스트수행이 종료된 경우 트랜잭션을 롤백시키는 것이다. 
• 즉, 테스트 실행이 시작되었을 때 자동으로 트랜잭션을 시작해서 데이터베이스 작업을 수행하고 결과를 검증한 후에 트랜잭션을 롤백시킴으로써 테스트 데이터들이 자동적으로 제거되도록 하는 것이다. 
• 각 개발자들의 테스트 로직은 트랜잭션에 의해 격리되기 때문에 상호 간에 영향을 미치지 않게 된다.

 

 

• Spring을 사용한다면 빈 컨텍스트가 한 번만 로딩되도록 하여 테스트가 빠르게 실행되도록 하며, 빈 컨텍스트에 선언된 빈들이 자동으로 테스트 클래스에 의존 주입되도록 하고, 매 테스트 메소드 실행 시 자동으로 트랜잭션을 시작하고 종료 시 롤백 시킴으로써 데이터베이스를 항상 동일한 상태로 유지될 수 있도록 할 수 있다.

 

 

 

 

 

• REPOSITORY 구현 클래스만 변경되었을 뿐 도메인 모델은 변합이 없다. 
• 이것이 바로 Domain-Driven Design, 낮은 결합도, 비 침투적인 인프라 스트럭처의 힘이다.

 

 

도메인을 닮은 어플리케이션

---

• 어플리케이션은 자신이 투영하고 있는 도메인과 오래도록 동고동락할 수 밖에 없다. 
• 따라서 가장 좋은 어플리케이션은 시간이 지남에 따라 도메인과 닮아가는 어플리케이션이 아닌가 생각된다.

 

 

• 그러나 시간이 지나면서 어플리케이션의 경우 도메인을 닮기 위해서는 시작부터 도메인을 염두에 두고 출발해야 한다. 
• 실제 도메인의 용어와 개념을 차용하여 어플리케이션을 구성하고, 도메인을 추상화한 단일 모델을 통해 개발을 이끌어 나가며, 비침투적인 인프라 스트럭처를 사용하여 도메인의 독립성을 보장하는 것이 그 출발점이 될 것이다.

 

 

• DOMAIN MODEL 패턴은 도메인과 어플리케이션 간의 표현적 차이를 최소화하기 위해 도메인 레이어를 구성하는 방법이다. 
• 그러나 DOMAIN MODEL을 구성하기 위한 원칙이나 비침투적인 인프라 스트럭처 없이 DOMAIN MODEL 패턴을 적용할 경우 프로젝트의 실패로 이어질 확률이 높다. 
• 물론 DOMAIN MODEL 패턴을 적용하는데 있어 가장 큰 어려움은 객체 지향 분석/설계 기술을 가진 팀을 구성하는 일일 것이다. 

 

 

 

 

참조

---

이터니티 - Domain-Driven Design의 적용