research

Larman + Fowler 통합 학습 전략

Larman + Fowler 통합 학습 전략

실전 접근 순서

Larman은 바로 실행 가능하고, Fowler는 전체를 알아야 한다는 느낌이 들 수 있다. 하지만 Fowler도 처음부터 다 알 필요 없다. 첫 두 결정만 해도 시작할 수 있다.

핵심: Fowler의 모든 패턴을 미리 결정하려 하지 않는다. Fowler 패턴은 "문제를 만났을 때 꺼내 쓰는 도구상자"이지, "미리 다 계획하는 청사진"이 아니다.

레이어 분리 역량을 키우는 법

"sub project를 추가해도 layer가 안 변한다"는 Fowler의 리트머스 테스트 그 자체다. 이 경지에 도달하는 방법:

처음부터 완벽하게 분리하는 게 아니라, 위반을 발견하고 고치는 사이클을 반복한다.

실전 훈련법:

  1. 먼저 만든다 — 완벽한 분리를 목표로 하되, 실수해도 괜찮다
  2. 리트머스 테스트를 스스로 돌린다 — 실제로 CLI를 만들 필요 없이, "어디를 중복 구현해야 하지?"를 머릿속으로 따져본다
  3. 위반 지점을 찾으면 리팩터링한다 — 이 한 사이클이 곧 하나의 iteration

예시: Controller에 추천 로직을 넣었다. 동작한다. 나중에 API 엔드포인트를 추가하려니 같은 로직을 또 써야 한다 — 이 순간이 "아, 이게 Domain에 있어야 했구나"를 체감하는 순간이다. 이걸 직접 경험해야 몸에 배지, 이론만으로는 안 된다.

DCD 설계 역량을 키우는 법

누군가가 만든 DCD를 이해하는 것과 빈 종이에서 만드는 것은 완전히 다른 역량이다.

빈 종이 연습법

  1. UC 하나를 골라 — 가장 핵심적인 것
  2. SSD를 직접 그려 — 시스템 이벤트가 뭔지 정의
  3. GRASP 원칙을 하나씩 적용하면서 Interaction Diagram 그려
    • "이 메시지를 누가 받아야 하지?"
    • "Information Expert에 따르면 Student가 성적 데이터를 가지고 있으니까 getGPA()는 Student에게"
    • "Creator에 따르면 Enrollment을 누가 만들어야 하지?"
  4. 결과로 DCD를 도출
  5. 기존 DCD와 비교 — 차이점이 뭔지, 왜 다른지 분석

처음에 틀리는 게 정상이다. Larman 자신도 "첫 설계는 나쁘다, iteration이 개선한다"고 말한다. 핵심은 왜 이 객체에 이 책임을 줬는지 GRASP 원칙으로 근거를 말할 수 있는가이다.

Fowler에 Iteration 적용하기

Fowler 자신도 이를 전제한다. "Active Record로 시작하고, 필요하면 Data Mapper로 전환하라"가 대표적 예시.

아키텍처 결정의 Iteration

| Iteration | 발생한 문제 | 도입할 Fowler 패턴 | |-----------|-----------|-------------------| | 1 | (시작) | 가장 단순한 조합으로 시작 | | 2 | 비즈니스 규칙이 복잡해짐 | Transaction Script → Domain Model | | 3 | 클래스-테이블 불일치 | Active Record → Data Mapper | | 4 | 외부 시스템(LLM) 연동 | Gateway 패턴 | | 5 | N+1 쿼리 성능 문제 | Lazy Load | | 6 | 동시 수정 충돌 | Optimistic Lock | | 7 | 여러 객체 한번에 저장 | Unit of Work |

각 패턴은 문제가 발생했을 때 도입하는 것이지, 미리 전부 깔아놓는 게 아니다.

"Fowler를 전부 알아야 한다"는 걱정에 대해

전부 알 필요 없다. 필요한 건 "이런 문제가 생기면 이런 패턴이 있다"는 인덱스가 머릿속에 있는 것이다. 구체적 구현은 문제를 만났을 때 해당 패턴 문서를 찾아보면 된다. 그게 PoEAA 노트들(00-reading-guide부터 시작)의 역할이다.

정리: 두 방법론의 Iteration 리듬

Iteration N:
  1. UC 선택 (Larman)
  2. SSD 작성 (Larman)  
  3. Interaction Diagram + DCD (Larman + GRASP)
  4. 구현하면서 아키텍처 문제 발견 (실전)
  5. Fowler 패턴으로 해결 (Fowler)
  6. 리트머스 테스트로 레이어 분리 검증 (Fowler)
  → Iteration N+1로

Larman이 각 iteration의 엔진이고, Fowler가 iteration 중 발생하는 아키텍처 문제의 해법이다.

← research 목록으로홈으로