02장 - 도메인 논리 구성

트랜잭션 스크립트

도메인 논리를 저장하는 가장 간단한 방식이다.

프레젠테이션에서 입력 받고, 유효성 검사와 계산을 통해 입력을 처리하고, 데이터베이스에 데이터를 저장하고, 다른 시스템에서 작업을 호출하는 프로시저다. 그런 다음 필요에 따라 응답을 구성하고 서식을 지정하는 계산을 수행하고 프레젠테이션에 응답한다. 기본 구성은 사용자가 수행할 각 작업마다 프로시저를 하나씩 만드는 것이다.

 

장점:

트랜잭션 스크립트는 대부분이 이해할 수 있는 간단한 절차 모델이다. 데이터 원본 계층과 함께 사용하기에 적합하다. 트랜잭션의 경계를 설장하기가 쉽다.

 

단점:

복잡도가 상승한다. 코드가 많이 중복된다. 결과적으로 명확한 구조가 없어진다.

도메인 모델

복잡한 논리를 객체로 해결하기 위한 모델이다. 한 루틴이 한 가지 사용자 작업의 논리를 모두 처리하는 것이 아니라 각 객체가 관련된 논리의 일부를 담당하게 한다. 도메인 모델을 사용하는 데 따르는 비용은 사용의 복잡성과 데이터 원본 계층의 복잡성이다.

 

테이블 모듈

도메인 모델과의 가장 중요한 차이는 도메인 모델은 데이터베이스에서 각 계약마다 계약 인스턴스가 있지만, 테이블 모듈은 인스턴스가 단 하나라는 것이다. 테이블을 기준으로 도메인 논리를 구성하기 때문에 구조를 만들고 중복을 찾아 제거하기가 수월하다.

 

다만 상속, 전략, 그리고 다른 객체지향 패턴과 같이 도메인 모델에서 논리의 세부 구조를 만드는 데 사용하는 여러 기법은 사용할 수 없다.

 

서비스 계층

도메인 논리를 처리하는 일반적인 방법은 도메인 계층을 둘로 나누는 것이다. 이 경우 서비스 계층을 도메인 모델 위에 배치한다.

이렇게 둘로 나눈 경우 프레젠테이션 계층은 애플리케이션의 API 역할을 하는 서비스 계층과 단독으로 상호작용한다.

서비스 계층은 명확한 API를 제공하며 트랜잭션 제어와 보안과 같은 기능을 넣기도 좋은 위치이다.

서비스 계층을 사용할 때는 여기에 얼마나 많은 동작을 넣을지 결정하는 것이 아주 중요하다. 가장 소극적 사례는 서비스 계층을 파사드로 만들고 모든 실제 동작을 기반 객체에 넣은 다음, 서비스 계층이 파사드에 대한 호출을 하위 객체로 전달하게 하는 것이다.

 

극단적 사례는 대부분의 비즈니스 논리를 서비스 계층 안의 트랜잭션 스크립트에 넣는 것이다. 이 경우 기본 도메인 객체는 아주 간단하며 데이터베이스와 일대일이므로 활성 레크도 같은 간단한 데이터 원본 계층을 사용할 수 있다.

 

두 방법의 중간적인 성격으로서 행동을 혼합한 컨트롤러-엔터티 형식이 있다. 요점은 한 트랜잭션이나 유스 케이스에 적용되는 논리를 트랜잭션 스크립트에 넣는 것이며, 일반적으로 이를 컨트롤러 서비스라고 한다. 여기서 말하는 컨트롤러는 유스 케이스 컨트롤러이다.

둘 이상의 유스 케이스에서 사용되는 동작은 엔터티라고 하는 도메인 객체에 배치한다. 유스 케이스 컨트롤러는 코드 중복을 많이 유발한다.