1부 이야기 - 도메인 논리 구성

마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴을 읽고 정리한다.

1부 이야기에서는 다양한 개념과 발전 과정을 말한다.

작성 시점은 20년 전으로 당시와 지금의 용어가 약간 다를 수 있고, 더 이상 사용 안 하는 것도 있을 수도 있다.

자세한 내용이 궁금하면 읽어보는 걸 권한다.

엔터프라이즈 애플리케이션 아키텍처 패턴(재출간판) - 교보문고

---

도메인 논리 구성

트랜잭션 스크립트, 도메인 모델, 테이블 모듈 세가지 주요 패턴으로 분리했다. 

트랜잭션 스크립트는 도메인 논리를 저장하는 가장 간단한 방식으로, 프레젠테이션에서 입력을 받고, 유효성 검사와 계산을 통해 처리한 뒤 데이터베이스에 데이터를 저장하고, 다른 시스템의 작업을 호출하는 프로시저다. 그다음 필요에 따라 응답을 구성하고 프레젠테이션에 응답한다. 

트랜잭션 스크립트는 여러 장점이 있다.

- 대부분의 개발자가 이해할 수 있는 간단한 절차적 모델

- 행 데이터 게이트웨이나 테이블 데이터 게이트웨이를 적용해 데이터 원본 계층과 함께 사용하기 적합

- 트랜잭션위 경계 설정이 쉽다.

 

단점은 도메인 논리가 늘어나면 복잡도가 상승한다. 공통 서브루틴(메서드)을 뽑아내도 한계가 있다.

하나의 트랜잭션에서 로직을 해결한다.

이 문제를 해결하기 위한 객체지향적 방법이 도메인 모델이다. 

트랜잭션 스크립트 대신 도메일 모델을 사용하는 것이 객체지향 지지자들이 이야기하는 패러다임의 전환을 의미한다. 하나의 루틴이 사용자의 작업 논리를 모두 처리하는 것이 아니라 각 객체가 관련된 논리의 일부를 담당하게 한다.

 

도메인 모델에 익숙해지면 복잡한 논리를 체계적으로 관리하는 다양한 기법을 활용할 수 있다. 새로운 알고리즘이 필요하면 새로운 객체를 추가하는 식으로 편하게 대처할 수 있다. 트랜잭션 스크립트 경우엔 해당 로직에 조건을 추가해야 한다.

사고방식을 전환해도 데이터베이스 매핑은 변화가 없어야 한다. 도메인 모델이 풍성해질수록 데이터베이스 매핑은 복잡해진다. 

객체간 상호작용으로 해결

테이블 모듈은 도메인 모델과 비슷해 보이지만 도메인 모델은 데이터베이스에서 각 계약마다 계약 인스턴스가 있지만, 테이블 모듈은 인스턴스가 단 하나다.

테이블 모듈은 레코드 집합과 함께 사용하도록 설계되어 있어서, 클라이언트는 데이터베이스 쿼리를 수행해 레코드 집합을 얻고 이 레코드 집합을 인수로 전달해 계약 객체를 만든다.

조회된 레코드 집합으로 동작한다.

테이블 모듈은 여러 면에서 트랜잭션 스크립트와 도메인 모델의 중간적인 성격을 많이 가진다.

 

---

선택

세 패턴 중 어떤 것을 선택해야 할지는 도메인 논리의 복잡도에 달려있다.

복잡도에 따른 효율성

필자는 개발팀의 수준이 높으면 도메인 모델을 선호한다.

일단 선택을 하면 다른 패턴으로 바꾸는 것은 불가능하진 않지만, 매우 까다로울 수 있다.

트랜잭션 스크립트를 선택했는데 나중에 잘못된 길이 된다면, 지체 없이 도메인 모델로 리팩토링 시작한다.

 

세 패턴은 상호 배타적인 선택은 아니다. 일부 도메인 논리에는 트랜잭션 스크립트를 사용하고, 나머지에는 테이블 모듈이나 도메인 모델을 사용하는 경우도 있다.

---

서비스 계층

도메인 논리를 처리하는 일반적인 방법은 도메인 계층을 둘로 나누는 것으로, 서비스 계층 기반이 되는 도메인 모델이나 테이블 모듈 위에 배치한다. 이렇게 둘로 나눈 경우 프레젠테이션 계층은 애플리케이션의 API 역할을 하는 서비스 계층과 단독으로 상호작용한다.

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

서비스 계층을 사용할 때는 얼마나 많은 동작을 넣을지 결정하는 게 아주 중요하다.

 

가장 소극적 사례는 파사드로 만들고 모든 실제 동작을 객체에 넣어, 서비스 계층이 파사드에 대한 호출을 하위 객체로 전달한다. 이 사례는 서비스 계층이 유스 케이스를 반영된 사용하기 쉬운 API를 제공한다.

반대되는 극단적 사례는 서비스 계층 안에 트랜잭션 스크립트에 대부분의 비즈니스 논리를 넣는 것이다. 이러면 도메인 객체는 아주 단순하고 활성 레코드 같은 간단한 데이터 원본 계층을 사용할 수 있다.

 

위의 두 방법에서 중간적인 성격을 가지는 컨트롤러-엔티티 형식이 있다. 이 형식은 한 트랜잭션이나 유스 케이스에 적용되는 논리를 트랜잭션 스크립트에 넣는 것이며, 이를 컨트롤러나 서비스라고 하며 유스 케이스 컨트롤러라 칭한다.(모델 뷰 컨트롤러의 입력 컨트롤러나 애플리케이션의 컨트롤러와는 다르다)