Domain Model vs Transaction Script

비즈니스 로직을 코드로 구현하는 2가지 방법에 대해 알아보겠습니다.
참고 문서를 번역하고 정리했어요.

 

Domain Model

데이터와 행동을 도메인에 포함시키는 객체 모델입니다. 비즈니스 로직이 매우 복잡해질 수 있습니다. 규칙과 로직이 다양한 케이스를 표현하는데, 이러한 복잡함 속에서 객체가 동작하도록 설계됩니다. 도메인 모델은 서로 연결된 객체 웹을 만듭니다. 각 객체는 하나의 의미있는 단위가 됩니다 (책임을 가지고 특정 행동을 수행)

각 객체가 의미있는 행동을 수행한다

 

 

Transaction Script

프레젠테이션 계층으로부터 전달된 하나의 요청을 처리하는 절차 안에 비즈니스 로직을 구성합니다. 예를 들어 도메인 객체에는 비즈니스 로직을 포함하지 않고, 서비스 계층에 해당 코드를 최대한 구현하는 것입니다.

하나의 계층에 집중된 비즈니스 로직

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

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

 

 

생각

현제 제가 속한 파트는 도메인 모델을 지향하여 개발하고 있고, 각 엔티티 객체에 고유한 책임을 부여하려 합니다. 책임이 분산되기 때문에 코드를 유지보수하기 더 쉬워지는 것 같습니다. 하지만 복잡한 비즈니스 로직을 구현할 때 머리가 많이 아픕니다. 메세지를 통해 객체 간 관계를 어떻게 구성해야 할 지, 어떤 책임을 부여해야할 지 정말 어려웠던 경험이 있기도 합니다.

트랜잭션 스크립트는 거의 사용해보지 않았는데, 유사한 비즈니스 코드가 다양한 곳에 중복될 수 있기 때문에 유지 보수에 어려울 것입니다. 그렇지만 단순하기에 쉽습니다. 도메인 모델과 달리 복잡하게 생각하지 않아도 될 것 같습니다. 그대로 로직을 구현해나가면 됩니다. 비즈니스 로직이 정말 간단할 경우 사용해도 될 것 같습니다.

 

 

참고

P of EAA: Domain Model

P of EAA: Transaction Script