Larman vs Fowler — 두 방법론의 관계
핵심 구분
둘 다 프로세스 방법론이 아니다. 관점의 초점이 다를 뿐이다.
Larman — 객체 책임 할당 방법론 : "이 유스케이스를 실현하려면 어떤 객체가 어떤 메시지를 주고받아야 하는가?"
Fowler — 아키텍처 결정 프레임워크 : "이 시스템은 어떤 패턴 조합으로 구성해야 하는가?"
각자의 영역
Fowler가 "Domain Model을 쓰겠다"고 결정하는 순간, 그 Domain Model 내부를 구체적으로 설계하는 방법이 Larman이다. Fowler 책에는 Domain Model 내부를 어떻게 설계하는가에 대한 체계적 프로세스가 없고, 그 빈자리를 Larman이 채운다.
두 책의 범위 비교
| 설계 질문 | Larman | Fowler | |----------|--------|--------| | 시스템 경계 정의 (Use Case, SSD) | ✅ 핵심 | ❌ 다루지 않음 | | 개념 모델 (Domain Model) | ✅ 핵심 | △ 언급만 | | 객체 책임 할당 (GRASP) | ✅ 핵심 | ❌ 다루지 않음 | | 객체 협력 설계 (Interaction Diagram) | ✅ 핵심 | ❌ 다루지 않음 | | Presentation 계층 패턴 | △ Controller만 | ✅ MVC, Front Controller, Template View 등 | | Domain 계층 패턴 선택 | ❌ Domain Model 전제 | ✅ TS vs TM vs DM 비교 | | Domain 계층 내부 설계 | ✅ GRASP + GoF | △ Strategy 등 언급 | | Data Source 패턴 | △ 후반부에 간략히 | ✅ AR, DM, TDG, RDG 상세 비교 | | O-R 매핑 전략 | ❌ | ✅ Identity Map, Lazy Load, UoW 등 | | 동시성 | ❌ | ✅ Optimistic/Pessimistic Lock | | 분산 | ❌ | ✅ Remote Facade, DTO |
"Top-down"이라는 오해
Fowler를 "top-down"이라 부르기 쉽지만, 실제로는 결정의 순서를 제안하는 것이지 위에서 아래로 설계를 내려가는 게 아니다:
- 도메인 복잡도 판단 → Domain Logic 패턴 선택
- 클래스-테이블 매핑 관계 → Data Source 패턴 선택
- UI 요구사항 → Presentation 패턴 선택
- 그 외 → 동시성, 세션, 분산 결정
각 결정은 독립적이면서도 서로 영향을 주는 관계이지, 계층적 하향식이 아니다. 예를 들어 Data Source 패턴 선택은 Domain Logic 패턴에 의존하지만, Presentation 패턴 선택은 독립적이다.
프로젝트에서의 통합 사용법
실제 프로젝트에서 두 방법론을 함께 쓰는 흐름:
Fowler는 큰 틀을 잡아주고, Larman은 각 iteration 안에서 도메인 객체 설계를 구체화한다. 10-dcd-to-database-bridge에서 다루었듯이, Larman의 DCD가 끝나는 지점에서 Fowler의 Data Source 패턴이 시작된다.