Whiteship's Note


Code Organization Guidelines for Large Code Bases - 유겐 휄러

Spring/TSE 2006 : 2008.07.17 15:43


왜 코드 조직화를 걱정하는가?
패키지 interdependencies
모듈 나누기와 레이어링
커다란 코드 기반 진화시키기
케이스: 스프링 진화
아키텍처 분석 도구

왜 코드 조직화를 걱정하는가?
- 전체 코드 이해를 돕고, 보다 편하게 네비게이션 하기 위해서.
- 자바에는 패키지와 서브 패키지 개념을 제공하긴 하지만, 어떻게 적용해야 할지에 대한 권고 같은건 없다.

신경써야 할 것들
- 코드는 원래 구조에서 계속 진화할 필요가 있다.
- 리팩터링과 애자일 개발은 좋다. 근데 그렇게 개발하면서도 이전에 배포한 코드와의 호환성은 어떻게 유지할 것인가..
- 원래 설계에서 의도하지 않았던 의존성들이 모듈을 나누다 보면 생길 수 있다.
- (점점 커지나까) API를 유지하면서 모듈을 좀 더 세밀한 모듈로 조갤 수 있을런지..

패키지 상호의존성
- 패키지 구조를 설계하는 건 놀랍도록 중요하다.

왜 단방향 의존성이 중요한가?
- 즉, 왜 순환 참조(CD)가 안 좋을까?
- 코드를 악화 시킨다,.
- 패키지 재사용에 제한이 생긴다.
- B를 사용하려면 A를 컴파일 해야 하는데 A는 다시 B를 컴파일 해야 하는 상황 발생한다.

그러니까
- CD를 없애라.
- 패키지들을 개념적인 모듈로 묶어라.
- 모듈을 만들어 낼 땐 개념적인 경계와 더불어 배포도 고려해야 한다.

모듈 decomposition과 레이어링
- 모듈의 특성(다른 모듈과 낮은 종속성, 모듈내에선 높은 결집도)
- 모듈은 소스 관리와 배포 단위 만듬이나 개념적인 단위다.
  - cognitive 오버로드를 피하라.
  - 개별적으로 사용 할 수 있어야 한다.(전체 시스템의 일부 기능)
- 모듈 간에 CD를 가지고 있으면 안 된다.
- 모듈 간에 의존성들은 그들이 가지고 있는 패키지에 의해 만들어진다.
- 레이어링은 패키지 구조에 있어서 중요한 논리 뷰다. 상위 계층에서 하위 계층을 참조하고 그 반대로는 안 되도록..
- 모듈 레이러링 보다는 개발 consideration에 의해 도출 된다.

그러니까
- 코드 베이스 내에서 자연스러운 개념적인 경계를 만들어라.
  - 자연스러운 패키지 네이밍
  - 편한 네비게이션
- 가장 힘든 도전은 코드를 진화시키는 거다.
  - code deteriorate를 놓치지 않고..
  - 아키텍처 질을 떨어뜨리지 않고..
- 하위 호환성과 아키텍처 품질 사이의 트레이드오프를 생각해야 한다.
  - 완전 100% 하위 호환성은 보장할 수가 없게 된다.
  - 물론 가끔 아키텍쳐 품질을 양보하지 않아도 되는 방법이 항상 있을 수 있음을 생각해야 한다.
- 물론 몇 가지는 쉽게 바꾸기가 힘들 것이다.
  - public API에 있는 패키지 이름
  - 그렇다고 정리하는걸 주저하면 안된다. 아키텍처 품질을 위해 deprecation 해버리자.

케이스 스터디: 스프링
- 스프링 코드 복잡한 SPI, 다양한 곳에서 사용하는 많은 API, 다양한 요구사항 속에서 3.5년을 어떻게 버텨왔을까?
- 매우 엄격한 아키텍쳐 관리
  - loosely counpled package with welldefined interdependencies
  - 패키지 단에서 CD가 없다. 만약에 CD가 생기면 다시 살펴보고 심각하게 고민하다.
- 스프링이 가지고 있던 CD (수정 후 dependency)
  - core <-> util (core <- util)
  - beans <-> aop (beans <- aop)
  - beans <-> context (beans <- context)
  - transaction <-> dao (transaction -> dao)
  - transaction <-> jdbc (transaction -> jdbc)
(소스 코드로 좀 보여주지 말로만 설명하네. 힘들게 시리 ㅠ.ㅠ)

CD 확인하는 도구
- JDepend
- SonarJ
- 공식 배포 하기 전에 JDepend를 한 번 돌려보는 건 어떨까!!
top


TSE 2006(Applying Domain Design in the Enterprise with AspectJ)

Spring/TSE 2006 : 2007.12.06 09:27


AspectJ In Action의 저자답게 AspectJ로 DDD를 돕는 여러가지 방법을 설명해줬습니다.

• Overview of Domain-driven design
• Aspects for crosscutting infrastructure
• Aspects for fine-grained DI
• Aspects for domain logic
• Aspects for enforcing DDD best
practices
• Proceeding towards DDD

이런 순서대로 발표가 진행됐는데, 토비님께서 마소에 기고하셨던 내용과 비슷한 내용들이 초반에 언급되었고 그 뒤로는 AspectJ를 사용하여 DDD 구현에 도움이 되는 방법들을 소개해 줬습니다.
  1. Service Layer에서 Aspect성 기능들을 Aspect로 구현하기.
  2. Aspect 사용해서 Repository나 Facade나 Service 객체들을 도메인에 DI 하기.
  3. 도메인 로직 중에 Aspect성 기능들을 Aspect로 구현하기.
  4. 아키텍처 정책을 수행하도록 강제하는 기능들을 Aspect로 구현하기.(web에서 Repository 호출하면 Eclipse에서 error로 표시하도록, DI사용해서 주입해야 할 것들을 명시적으로 new 하지 못하도록, ...)
마지막으로 다음과 같은 '사고의 흐름'을 권장해줬습니다.

• 도메인 엔티티와 도메인 로직부터 시작하기
– Basic domain-driven and object-oriented principle
• 시작할 때 기본적으로 service 계층은 없다고 생각하기
– See how far you can get
– Add service level as required
• 구현과 관련된 규칙들을 강제하기
• DDD로 리팩터링하기.
top


TSE 2006(The Art of Domain Modeling)

Spring/TSE 2006 : 2007.12.03 22:42


Keith Donald가 발표를 했는데, 전반후와 후반부로 나눠서 전반부는 Domain Modeling에대한 이론을 설명하고, 후반부는 특정 사례를 들어 모델링을 수행하고 모델을 코드로 구현하는 과정을 보여주었습니다.

이론 부분에서 인상 깊었던 부분.
  • 도메인 모델링은 실제 세상 전부를 다루는 것이 아니라 영화처럼 특정 시점에서의 세상을 표현하는 것이라는 것.
  • 효율적인 모델링 요소
    • 모델을 코드로 바인딩 - 모델의 가용성을 테스트에 일찍 그리고 자주 반영하기 위해
    • Knowledge-rich model 정제하기 - 풀어야할 문제의 핵심 복잡성을 잡아내가 위해
    • 공유 언어에 익숙해지기 - 모델에 기반한 의사소통을 위해
    • 브레인스토밍과 실험
이밖에도 좋은 말을 많이 한 것 같은데 좀 어렵네요.

실습 부분에서 인상 깊었던 부분
  • 오.. 얼핏 TDD
  • 맥 사용이 불편하신 듯.. 하지만 맥을 좋아하시는 듯
  • 라이브 코딩이 약간 어색..
코딩을 빠르게 멋지게 하는 모습이 중요한 것이 아니기 때문에 별로 상관없었습니다. 모델을 바로 코드로 검증하려는 모습이 중요했습니다. 테스트 코드는 거의 하나의 시나리오를 보여주고 있었고, 해당 테스트를 실행하기 위해 여러 도메인 모델을 만들고 메소드를 구현했습니다.

top