Organizing Domain Logic

시스템 설계에서 가장 중요한 첫 번째 결정: 도메인 로직을 어떻게 구조화할 것인가. 이 선택이 나머지 모든 아키텍처 결정의 출발점이 된다.

세 가지 선택지

Transaction Script

각 비즈니스 트랜잭션(사용자 액션)마다 하나의 프로시저를 만든다. "호텔 방 예약" 요청이 들어오면 가용성 확인 → 요금 계산 → DB 저장을 하나의 스크립트 안에서 순차적으로 처리한다.

장점: 단순하고 직관적. 대부분의 개발자가 익숙한 절차적 모델. Row Data Gateway나 Table Data Gateway와 잘 맞는다. 트랜잭션 경계가 명확하다(스크립트 시작=트랜잭션 시작, 끝=커밋).

단점: 도메인 로직이 복잡해지면 코드 중복이 급증한다. 여러 트랜잭션이 비슷한 일을 할 때 공통 로직을 분리하기가 점점 어려워진다.

Domain Model

도메인의 명사들을 중심으로 객체 모델을 구축한다. 리스 시스템이면 Lease, Asset 같은 클래스를 만들고, 각 객체가 자기와 관련된 로직을 담는다. 배송 객체가 배송비를 계산하고, 주문 객체가 총액을 계산한다.

장점: 복잡한 도메인 로직을 체계적으로 다룰 수 있다. 상속, Strategy 패턴 등 OO 기법을 활용해 변형을 깔끔하게 처리한다. 새로운 비즈니스 규칙 추가가 새 Strategy 객체 추가로 끝난다.

단점: 학습 곡선이 가파르다(적응에 수개월 걸릴 수 있음). 가장 큰 문제는 관계형 DB와의 매핑 복잡성 — Domain Model이 풍부해질수록 05-data-source-patterns|Data Mapper가 필수가 되고, 그 구현이 무겁다.

Table Module

테이블당 하나의 클래스를 만들되, Domain Model과 달리 인스턴스가 하나다. Contract 테이블에 대해 Contract 객체가 하나 존재하고, Record Set을 받아서 여러 행을 일괄 처리한다. 특정 행을 다루려면 ID를 넘겨야 한다.

장점: Transaction Script보다 구조적이고, Domain Model보다 DB와의 매핑이 쉽다. Record Set 기반 GUI 도구와 궁합이 좋다.

단점: 상속이나 Strategy 같은 세밀한 OO 기법을 쓸 수 없다. Record Set 프레임워크가 없으면 의미가 없다.

선택의 기준

Fowler의 핵심 통찰: 도메인 로직 복잡도가 어떤 임계점을 넘으면, Transaction Script와 Table Module은 기능 추가 비용이 지수적으로 증가한다. Domain Model만이 복잡도 증가에 선형적으로 대응할 수 있다.

그 임계점이 정확히 어디인지는 아무도 모른다. Fowler는 농담 반 진담 반으로 "복잡도가 7.42를 넘으면 Domain Model을 쓰라"고 했지만, 아무도 도메인 로직의 복잡도를 정량화하는 방법을 모른다. 결국 경험 있는 사람의 판단이 필요하다.

Service Layer

Domain Model이나 Table Module 위에 얹는 얇은 계층. Presentation이 도메인과 대화하는 API 역할을 한다.

Service Layer를 어떻게 쓸지에는 세 가지 스타일이 있다:

Facade 스타일 (Fowler가 선호): Service Layer는 단순히 호출을 Domain Model로 위임. 트랜잭션 제어와 보안 체크만 담당.
Controller-Entity 스타일 (Jacobson 영향): 특정 Use Case에 종속된 로직은 Service에, 공통 로직은 Domain 객체에.
Rich Service 스타일: 대부분의 비즈니스 로직이 Service에 있고, Domain 객체는 단순한 데이터 홀더.

Fowler는 가능한 한 얇은 Service Layer를 권장한다. "처음에는 필요 없다고 가정하고, 필요해지면 그때 추가하라."

Larman과의 연결

Larman의 GRASP Controller 패턴으로 만든 클래스들이 바로 Service Layer의 역할을 한다. Use Case Controller(Register 등)가 시스템 이벤트를 받아 Domain 객체들에게 위임하는 구조는 Fowler가 말하는 "thin facade" Service Layer와 정확히 일치한다. Larman에서 도메인 모델을 기반으로 DCD까지 만들었다면, Fowler의 Domain Model 패턴을 자연스럽게 따르고 있는 것이다.