caffeine-library/Domain-Driven-Design

[question] Transaction Script Pattern

Closed this issue · 2 comments

emiling commented

질문

중간에 Transaction Script에 대해 말하고 있는데 우리가 알아본 Domain Entity Pattern과 함께 비교하여 알아보면 좋을 듯합니다.

배경

SMART UI와 LAYERED ARCHITECTURE의 중간쯤에 위치하는 해법도 있다. 예를들어 Folwer(2003) 에서는 트랜잭션 스크립트(Transaction Script) 를 설명하고 있는데, 트랜잭션 스크립트는 어플리케이션으로부터 UI를 분리해내지만 객체에 모델을 제공하지 않는다 (p.81)

연관 챕터

#19

emiling commented

Transaction Script

  • 결국은 비지니스 로직을 어디서/어떻게 처리할 것인가에 대한 견해
    • 절차적인 접근 방법 : Transcation Script Pattern
    • 객제지향적인 접근 방법 : Domain Model

정의/개념

https://martinfowler.com/eaaCatalog/transactionScript.html
https://en.wikipedia.org/wiki/Anemic_domain_model

Organizes business logic by procedures where each procedure handles a single request from the presentation.
(각 프로시저가 프레젠테이션의 단일 요청을 처리하는 프로시저별로 비즈니스 로직을 구성한다)

  • 대부분의 비지니스 어플리케이션은 일련의 트랜잭션(조회 및 변경)으로 생각할 수 있다.
  • 결국 이러한 트랜잭션이 생기는 이유는 클라이언트와 서버 시스템 사이의 상호작용에 일정량의 로직이 포함되어 있기 때문
    • 데이터베이스에 있는 정보를 표시하는 간단한 상호작용일 수도 있고 여러 단계의 유효성 검사나 계산로직이 포함되기도 함
  • 따라서 트랜잭션 스크립트는 이러한 로직을 주로 단일 프로시저로 구성하여 데이터베이스에 직접 호출하거나 얇은 데이터 레퍼(ex. ORM)를 통해 호출한다. 각 트랜잭션에는 고유한 트랜잭션 스크립트가 있지만 공통 하위 작업은 하위 프로시저로 나눌 수 있다.

장단점?

  • 이러한 구조의 패턴은 필연적으로 anemic domain model을 만들 수 밖에 없음
    • DDD 에서는 각각의 도메인 모델이 정보 전문가로써 자신의 역할을 수행하고 다른 도메인 모델과 협력하며 비지니스 로직을 수행함
    • 그러나 트랜잭션 스크립트 패턴에서 비지니스 로직은 도메인 객체를 상태의 변환하는 별도 클래스(transaction script)에서 구현됨
      • 객체가 갖고있는 상태를 외부에서 조작하고 있기 때문에 로직과 데이터가 분리됨
  • 비지니스 로직이 늘어날 수록 복잡해질 수 밖에 없고, 그에 따라 중복 코드(정확하겐 중복된 행위)가 발생할 수 있으므로 재사용성이 떨어짐
  • 구현이 간단하기에 간단한 비지니스 어플리케이션에는 적합할 수 있으며 복잡한 데이터베이스 매핑 계층을 생략할 수 있다는 장점이 있음

번외

그럼 DDD에서 트랜잭션 어떻게 처리할까요?

정말 트랜잭션 스크립트가 나쁜 패턴일까?

kth990303 commented

트랜잭션 스크립트 패턴의 계기?

  • 객체지향이 생겨나기 전에 있었던 패턴인 듯?
  • 그러나 객체지향이 생겨나게 되면서 트랜잭션 스크립트 패턴은 안티 패턴으로 여겨지게 됨.
    • (chatgpt) 복잡성이 낮은 심플한 로직을 작성할 때 편리함. 요즘은 규모가 매우 커지다보니 잘 사용하지 않게 됨.

함수형 프로그래밍의 등장

  • 함수형 프로그래밍은 객체지향과 다르게 세밀한 도메인 로직까지 작성하기 편리함.
  • 트랜잭션 스크립트 패턴의 단점을 보완하면서도 해당 패턴과 비슷하게 로직을 작성할 수 있을 듯.
  • 함수형 프로그래밍은 객체지향과 반대가 아니다. 객체지향의 반대는 절차지향이다.