시스템

복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다 - Ray Ozzie, Microsoft CTO

도시를 세운다면?

• 도시를 세운다면 혼자서 모든 사항을 직접관리할 수 있을까?
• 그것은 분가능하다, 전체적인 그림을 그리는 사람도 있지만 작은 사항에 집중하는 사람들도 존재해야한다
• 소프트웨어 팀도 이와 유사하다
• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬어짐
• 이번 장에서는 높은 추상화 수준, 직 시스템 수준에서 깨끗함을 유지하는 방법을 살펴봄

시스템 제작과 시스템 사용을 분리하라

• 제작(construction)은 사용(use)과 아주 다름

소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야함

• 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)임
• 관심사 분리는 우리 분야에서 가장 오래되고 중요한 설계 기법중 하나임

• 불행히도 대다수 애플리케이션은 시작단계라는 관심사를 분리하지 않음

• 체계적으고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대 안 됨

Main 분리

팩토리

의존성 주입

확장

• 처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신
• 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야함
• 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장해야함
• 이것이 반복적이고 점진적인 애자일 방식의 핵심
• 테스트 주도 개발, 리팩터링, 클린코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만듬
• 시스템 수준에서는 관심사 분리를 통해 ..

횡단 관심사

• EJB2 아키텍처는 일부 영역에서 관심사를 거의 완벽하게 분리
• 예를 들어 트랜잭션, 보안, 일부 영속적인 동작은 소스 코드가 아니라 배치 기술자에 정의

자바 프록시

• 자바 프록시는 단순한 상황에 적합
• 개별 객체나 클래스에서 메서드 호출을 감싸는 것이 좋은 예

순수 자바 AOP 프레임워크

• 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용
• POJO는 순수하게 도메인에 초점을 맞춤

AspectJ 관점

• 마지막으로 관심사를 분리하는 가장 강력한 도구는 AspectJ 언어
• AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어의 확장
• AspectJ에 대한 문법과 사용법을 익혀야하는 단점이 있지만 최근에는 애너테이션으로 적용가능

테스트 주도 시스템 아키텍처 구축

• 관점으로 관심사를 분리하는 방식은 그 위력이 막강함
• 비즈니스 로직을 POJO로 작성할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해짐

의사 결정을 최적화하라

• 한사람이 모든 의사결정을 하는것이 아닌 가장 적합한 사람에게 책임을 맡기는게 좋음
• 때로는 가장 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 함
  • 게으르거나 무책임해서가 아니라 최선의 결정을 내리기 위해서임

명백한 가치가 있을 때 표준을 현명하게 사용하라

• 표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉬움
• 적절한 경험을 가진 사람을 구하기 쉬움
• 좋은 아이디어를 캡슐화하기 쉬움
• 컴포넌트를 엮기 쉬움
• 그러나 표준을 만드는데 너무 오래 걸려 기다리지 못하거나 원래 표준을 제정한 목적을 잊어버리기도 함

시스템은 도메인 특화 언어가 필요하다

• DSL
• 좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 의사소통간격을 줄여줌

결론

• 시스템이 깨끗하지 못하면 도메인 논리를 흐리며 제품 품질을 떨어트림
• 이는 생산성을 떨어트리고 TDD의 장점을 사라지게함
• 시스템 설계이든 모듈 설계이든 실제로 돌아가는 가장 단순한 수단을 사용해야함