트랜잭션 스크립트 패턴과 도메인 모델 패턴

간단하게 보면 비즈니스 로직 구현을 어디에서 하는가에 따라 트랜잭션 스크립트 패턴과 도메인 모델 패턴으로 나뉘게 된다.

트랜잭션 스크립트 패턴

트랜잭션의 동작처럼 특정 기능의 플로우를 스크립트와 같이 하나의 메서드에 구현하는 방법

해당 패턴은 엔티티에는 비즈니스 로직이 거의 없으며, 서비스 계층에 비즈니스 로직이 집중되어 있다.

장점으로는 일반적으로 익숙한 방법이기에 구현이 쉽다는 점이 있으며, 각각의 기능에 대해 모듈화를 잘 한다면 효율도 좋게 나온다.

즉, 모듈화를 잘 한다면 쉽게 개발이 가능하며 효율도 좋다는 의미

하지만 로직이 복잡해질수록 코드가 난잡해지며, 도메인 분석/설계에 대한 개념이 약하기 때문에 코드의 중복을 막기 어렵다는 단점이 있다.

 

도메인 모델 패턴

해당 패턴은 대부분의 비즈니스 로직을 엔티티에 구현하며, 서비스 계층은 엔티티에 필요한 역할을 위임하는 역할로 구현하게 된다.

장점으로는 객체 지향 설계를 기반으로 하기 때문에 객체 지향의 장점을 그대로 상속받는다.

즉, 재사용성과 확장성, 유지 보수에 장점을 갖고 있기에 수정이 편하다는 의미

단점으로는 도메인 모델 구축에는 많은 시간과 노력이 들어가게 되고, 각 객체들의 관계 및 데이터베이스와의 매핑 등 고려해야 하는 점이 많기에 도메인 모델 구축 실력 및 경험이 부족한다면 도메인 구축 자체가 힘들 수 있다는 점이다.

 

결론

두 패턴 모두 장단점이 뚜렷하기 때문에 상황에 따라 잘 선택하여 사용하는 것이 좋다.

하나의 프로젝트에서도 상황에 따라 두 패턴을 모두 사용하여 진행할 수 있다는 점을 간과하지 말자 (혹시나 해서 적어봤다)