[Design Pattern] Domain Model Pattern vs Transaction Script Pattern

설계 방법론 중 DDD에 대해 공부하는 과정에서 과연 DDD를 적용하는 것이 과연 좋은 방법일까에 대해 고민하는 시간을 가졌습니다 🧐

DDD는 비즈니스 로직을 처리하기 위해 Domain Model Pattern 을 사용하는데,
마틴 파울러가는 비즈니스 로직 처리를 위한 또 다른 패턴인 Transaction Script Pattern 의 개념또한 정립했다고 합니다.

그래서 오늘은 Domain Model Pattern과 Transaction Script Pattern 에 대해 알아보며 각각 어떤 부분에서 장단점이 있는지 살펴보도록 하겠습니다 🙌

Domain Model Pattern

Domain Model Pattern의 경우 주로 DDD 방식을 이용할때 사용하며, Domain 부분에서 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용 하는 것을 의미합니다.

대부분의 비즈니스 로직이 엔티티 안에 구성되어 있으며, 서비스 계층은 엔티티에 필요한 역할을 위임하는 역할을 합니다.

즉, 엔티티 안에 비즈니스 로직을 가지고 객체지향을 활용하는 기법을 Domain Model Pattern이라고 합니다.

장점

객체 지향에 기반한 재사용성, 확장성, 유지 보수의 편리함이 있습니다.
한번 도메인 모델을 구축하면 유사한 기능을 가진 곳에 재사용이 가능합니다. 또한, 상속/인터페이스, 더 나아가 컴포넌트 개념을 바탕으로 도메인 모델을 개발하게 되면 무한한 확장성을 갖게 된다는 장점이 있습니다.

단점

하나의 도메인 모델을 구축하는데 많은 노력이 필요하다는 단점이 있습니다.
객체를 판별하고 객체들 간의 관계를 정립해야 하고, 데이터베이스 사이의 매핑에 대해서 고민해야하기 때문에 도메인 모델에 능숙한 개발자가 없을 경우 구축 자체가 힘들어질 수도 있습니다.

Transaction Script Pattern

Transaction Script Pattern는 엔티티에 비지니스로직이 거의 없고, 서비스 계층에서 비즈니스 로직을 처리하는 방법을 가리킵니다. 엔티티는 단순하게 데이터를 전달하는 역할이 되면서 서비스 로직이 커지게 됩니다.

트랜잭션 스크립트 모델로 구현한다면 엔티티는 DTO의 역할 만하고 위에 해당 비즈니스 로직이 서비스 계층으로 옮겨지게 됩니다.

이때 도메인 엔티티는 아무런 비즈니스 로직이 없는 POJO 클래스로 데이터를 전달하는 역할만 수행합니다.

대부분의 비즈니스 어플리케이션은 트랜잭션의 연속이나 마찬가지입니다. 특정 방식으로 조작된 데이터를 조회하거나, 데이터를 변경하기 위해 트랜잭션이 수행됩니다. 클라이언트 시스템과 서버 시스템 간의 상호작용은 어느 정도의 로직을 포함하는데, 케이스에 따라 정보를 간단하게 표시할 수도 있고, 검증 및 계산과 같은 단계를 수반할 수도 있습니다.

Transaction Script는 이러한 로직을 하나의 작업으로 구성하며, 데이터베이스를 직접 호출하거나 얇은 데이터베이스 래퍼를 이용합니다. 각 트랜잭션은 고유한 트랜잭션 스크립트를 가지고 있고, 이는 하위 작업들로 나누어질 수 있습니다.

장점

구현 방법의 단순함 때문에 구현이 매우 쉬우며 얼마나 모듈화를 잘 하느냐에 따라서 높은 효율을 낼 수 있다는 장점이 있습니다.

단점

비즈니스 로직이 복잡해질수록 난잡한 코드를 만들게 된다는 단점이 있습니다.
특히, 트랜잭션 스크립트 코드는 애초에 도메인에 대한 분석/설계 개념이 약하기 때문에 코드의 중복 발생을 막기 어려워지며, 트랜잭션 스크립트를 사용하게 되면 쉬운 개발에 익숙해지기 때문에 공통된 코드를 공통 모듈로 분리하지 않고 복사&붙이기 방식으로 중복된 코드를 발생할 가능성이 있습니다.

생각

저는 실제로 Domain Model Pattern보다 Transaction Script Pattern을 더 잘 사용하고 있습니다. (사실 DDD의 개념이 뚜렷하지 않아 사용해보겠다는 생각을 못했습니다..ㅎㅎ)

어떠한 방식이 좋다고 판단하기엔 아직 경험치가 부족하다고 생각하기 때문에 다양한 경험을 바탕으로 상황에 맞게 적절한 방식을 선택하는 방법이 좋다고 생각합니다.

저의 경우 Transaction Script Pattern을 주로 사용하고 있는데요, 비즈니스 코드가 다양한 곳에 중복될 수 있다는 문제점을 해결하기 위해 최대한 함수화를 하려고 노력하고 있긴 하지만 여러 상황을 고려해봐야겠다는 생각이 듭니다.

주로 Domain Model Pattern을 유지보수 측면에서 권장하고 있기 때문에 이를 반영하여 코드를 설계하는 연습도 필요하다고 느껴집니다.

해당 블로그 에는 Domain Model Pattern보다 Transaction Script Pattern을 권장하는 경우에 대해 설명하고 있는데 함께 읽고 다양한 경우를 고려해봐야겠네요 🧐

PS. 관련 내용이 클린코드 6장에 있다는 의견이 많아 해당 부분을 다시 읽어봐야겠습니다 :)

Reference

• https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model#the-domain-entity-pattern
• https://martinfowler.com/eaaCatalog/domainModel.html
• https://martinfowler.com/eaaCatalog/transactionScript.html
• https://www.inflearn.com/questions/117315/%EB%B9%84%EC%A7%80%EB%8B%88%EC%8A%A4-%EB%A1%9C%EC%A7%81%EA%B5%AC%ED%98%84-entity-vs-service