디자인 패턴

최근에 인프런 김영한님의 강의를 듣다가 비즈니스 로직 대부분을 Entity에 작성하는 것을 보게되었다.

하지만 처음 내가 Spring, SpringBoot를 배우고 Entity설계를 배울때는 Entity에는 데이터베이스에 쓰일 테이블과 칼럼만 정의하였고 Dto를 배우면서 toEntity나 ofEntity등의 함수정도만 정의하였다. 그 외 모든 비즈니스 로직은 서비스 계층에서 작성하는 방식으로 개발을 진행하였다.

이러한 두가지 디자인 패턴중 어떤 패턴이 더 좋은 패턴인지 알아보고 싶었다.

이 두방식이 디자인 패턴의 차이라고 한다.

이제 그 두가지 디자인 패턴을 알아보자.

도메인 모델 패턴

엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것
-> Domain부분에서 비즈니스 로직을 이용해 개발을 진행하는 것

도메인 모델 패턴 장점

객체 지향에 기반한 재사용성,확장성, 그리고 유지 보수의 편리함 필요에 따라 약간의 수정이 필요하지만 언제든지 재사용할 수 있다.

도메인 모델 패턴 단점

하나의 도메인 모델을 구축하는데 많은 노력이 필요하다.
객체를 판별하고 객체들 간의 관계를 정립해야 하고, 데이터베이스 사이의 매핑에 대해 고민해야한다.

트랜잭션 스크립트 패턴

엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것
-> Domain 부분이 아닌 Service 부분에서 비즈니스 로직을 이용해 개발을 진행하는 것

트랜잭션 스크립트 패턴 장점

구현 방법이 단순하기 때문에 구현이 쉽다. 높은 효율을 낼 수 있다.

트랜잭션 스크립트 패턴 단점

비즈니스 로직이 복잡해질수록 난잡한 코드를 만들게 되고 도메인에 대한 분석/설계 개념이 약하기 때문에 코드의 중복 발생을 막기 어렵다.

실제로 트랜잭션 스크립트 패턴으로 두번의 프로젝트를 진행 한 결과 트랜잭션 스크립트 패턴의 장,단점을 확실히 알 수 있었다.

김영한 님의 강의를 들으면서 도메인 모델 패턴을 몸소 체험해봐야 겠다.