제작과 사용은 아주 다르다.
소프트웨어 시스템은(애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.
핵심은 시작단계를 분리한다는 말이다.
아키텍쳐 관점으로는 Main 이 그 역할을 하고 있다.
생성과 관련된 코드는 모두 main 이나 main 이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.
애플리케이션은 그저 객체를 사용할 뿐..
객체가 생성되는 시점 을 애플리케이션이 결정할 필요가 있을 경우 팩토리를 사용한다.
- 추상 팩토리 패턴
- 팩토리 메소드 패턴
SRP 을 지킬 수 있도록 한다.
처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞쳐
시스템을 조정하고 확장하면 된다. 반복적이고 점진적인 확장이 애자일의 확장이다.
그렇다면 시스템 아키텍쳐는 어떠할까? 사전계획이 필요한가? 사실 시스템 아키텍쳐는 복잡한 아키텍쳐로 조금씩 키울 수 없다는 현실이 정확하다.
소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍쳐는 점진적으로 발전할 수 있다.
위와 같이 관심사를 분리한다면 어떤 이점이 있는가? 코드 수준에서 아키텍쳐 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍쳐 구축이 가능해진다.
최선의 시스템 구조는 각기 POJO(또른 다른)객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.
모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능하다.
가장 적합한 사람에게 책임을 맡겨라. 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹는다. 성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다.
관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다. 이런 기민한 덕택에 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.
깨끗하지 못한 아키텍쳐는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
모든 추상화단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.
시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명실하자