Putting It All Together

지금까지의 패턴들을 실제 프로젝트에서 어떻게 조합할 것인가. Fowler가 준 의사결정 트리를 정리한다.

결정의 순서

모든 것은 도메인 계층 선택에서 시작한다. 이 결정이 데이터 소스, 프레젠테이션까지 연쇄적으로 영향을 미친다.

경로별 상세

경로 A: Transaction Script + Gateway

상황: 단순한 CRUD, 비즈니스 규칙이 거의 없는 경우.

• Data Source: Row Data Gateway 또는 Table Data Gateway
• Record Set 도구가 있으면 Table Data Gateway
• O/R 매핑 패턴은 거의 불필요 (in-memory 구조가 DB와 거의 동일)
• 동시성은 대부분 스크립트=트랜잭션이라 단순. 편집-저장 분리 시 optimistic-offline-lock|Optimistic Offline Lock

경로 B: Table Module + Table Data Gateway

상황: Record Set 기반 프레임워크를 쓰는 환경 (.NET 등).

• Table Data Gateway가 Record Set을 반환하고, Table Module이 이를 조작
• Record Set이 동시성 제어까지 내장하면 Unit of Work 역할도 겸함
• 이 조합에서 Transaction Script를 쓸 이유가 없다

경로 C: Domain Model + Active Record

상황: 도메인 모델은 필요하지만, 클래스가 테이블과 거의 1:1인 경우.

• Active Record가 DB CRUD와 도메인 로직을 모두 담당
• Table Data Gateway나 Row Data Gateway로 살짝 분리할 수도 있으나 큰 차이 없음
• 복잡해지면 경로 D로 전환 고려

경로 D: Domain Model + Data Mapper

상황: 풍부한 도메인 모델, 상속·Strategy·복잡한 연관 관계가 필요한 경우.

• Data Mapper가 도메인과 DB의 완전 분리를 보장
• Unit of Work 강력 추천 (동시성 제어의 핵심)
• O/R 매핑 도구 구매를 강력 권장 — 직접 구현은 비용이 막대하다

Presentation 계층

도메인 선택과 비교적 독립적으로 결정할 수 있다.

웹 vs 리치 클라이언트: 가능하면 웹. 배포·유지보수가 압도적으로 쉽다. 리치 클라이언트는 반응성이나 오프라인 작업이 필수일 때만.

MVC 필수: 웹이든 리치 클라이언트든, Model-View-Controller 분리는 기본.

Controller 선택: 문서 중심 사이트면 Page Controller, 복잡한 네비게이션이면 Front Controller.

View 선택: Template View(JSP, Razor 등)가 대세. Transform View(XSLT)는 테스트 용이성이 장점. 다중 룩앤필이면 Two Step View.

분산 관련

Fowler의 첫 번째 법칙: "객체를 분산하지 마라." 모든 것을 하나의 프로세스에서 돌려라. 불가능할 때만 Remote Facade와 Data Transfer Object를 도입하되, 이는 복잡성을 크게 높이는 "complexity booster"다.

변경 불가능한 결정은 없다

Fowler의 핵심 메시지: 아키텍처 리팩터링은 어렵지만 불가능하지 않다. 그래서 세 가지 기술적 실천을 강력 권장한다:

1. Continuous Integration — 변경의 충돌을 빨리 발견
2. Test Driven Development — 변경해도 기존 기능이 깨지지 않음을 확인
3. Refactoring — 구조를 안전하게 개선

이 세 가지가 있으면, 초기 결정이 틀렸더라도 바로잡을 수 있다.

우리 프로젝트에의 적용

Academic Life Management System:

• 과목 추천, LLM 연동 등 복잡한 도메인 로직 → Domain Model
• C++/Drogon + SQLite/MySQL → Active Record로 시작, 필요시 Data Mapper로 진화
• 웹 프레젠테이션 → MVC (Drogon이 기본 제공)
• 단일 프로세스 → 분산 패턴 불필요

이 결정이 iteration0-guide|Iteration 0의 기술 스파이크에서 검증해야 할 핵심 가설이다.