도시를 세운다면?
여러분이 도시를 세운다면 온갖 세세한 사항을 혼자서 직접 관리할 수 있을까?
아마도 불가능 하리라
도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다.
그래서 큰그림을 이해하지 못할지라도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다.
흔히 소프트웨어 팀도 도시처럼 구성한다.
높은 수준의 추상화, 즉 시스템 수준에서 깨끗한을 유지하는 방법을 살펴본다.
이 챕터에서는 주로 DI, 횡단 관심사를 주제로 다루고 있다.
자바를 활용하여 순수 프록시를 생성을 하는 예제도 포함되어있다.
POJO
특정 기술에 종속되지 않는 순수한 자바 객체를 의미합니다.
AspectJ 구문의 설명도 진행이 된다. DI, IoC, Aop, 자바 프록시 기술은
다른 구문에서 정리할 예정이므로 넘어간다.
테스트 주도 시스템 아키텍처 구축
최선의 시스템 구조는 각기 POJO(또는 다른) 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다.
의사 결정을 최적화하라
모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다.
관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다.
명백한 가치가 있을 때 표준을 현명하게 사용하라
건축을 현자을 보면 여러 세기 동안 압박 하에 발전한 최적된 부품과 방법과 표준이 있다. EJB2는 단지 표준이라는 이유만으로 많은 팀이 사용해다.
아주 과장되게 포장된 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례를 많이 봤다.
어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.
시스템은 도메인 특화 언어가 필요하다.
건축 분야 역시 필수적인 정보를 명료하고 정확하게 전달하는 어휘, 관용구, 패턴이 풍부하다 소프트웨어 분야에서도 최근 들어 DSL이 새롭게 조명 받기 시작했다.
도메인 특화 언어를 사용하면 고차원 정책에서 저차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다.
결론
시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.
시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.
