코드뿐만 아니라 시스템도 깨끗해야 한다.
깨끗하지 못한 아키텍처는 도메인 논리를 흐리고 기민성을 떨어뜨린다.
-> 도메인 논리가 흐려지면 제품 품질이 떨어진다.
-> 기민성이 떨어지면 생산성이 낮아진다.
시스템이든 개별 모듈이든, 돌아가는 가장 간단한 수단을 사용해야 한다.
1. 시스템 제작과 시스템 사용 분리
제작과 사용은 매우 다르다.
따라서 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비과정과, 그 이후의 런타임 로직을 분리해야 한다.
분리되지 않은 로직의 예는 다음과 같다.
public Service getService() {
if (service == null)
service = new MyServiceImpl(...);
return service
}위와 같은 예는 초기화 지연(lazy evaluation) 기법으로, 분명 장점이 존재한다.
하지만 런타임 로직과 객체 생성 로직이 뒤섞여 모듈성이 약화되었다.
설정 논리와 일반 실행 논리를 분리하기 위한 방법은 몇 가지가 있다.
-
Main 분리
시스템 생성과 관련된 코드는 모두 main으로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정.
main함수에서 시스템에 필요한 객체를 생성하여 이를 애플리케이션에 넘기면, 애플리케이션은 객체를 사용하기만 할 뿐 main에 대해서는 알지 못한다. -
팩토리
객체가 생성되는 시점을 애플리케이션이 결정해야할 경우에도, ABSTRACT FACTORY 패턴을 사용함으로써 분리할 수 있다. 위 그림에서 애플리케이션은 객체 LineItem의 생성 시점을 결정하지만 LineItem을 생성하는 코드에 대해서는 알지 못한다. -
의존성 주입
의존성 주입은 제어 역전(Inversion of Control) 기법을 의존성 관리에 적용한 매커니즘이다. 객체는 의존성 자체를 인스턴스로 만드는 책임을 전담 매커니즘에 넘겨주는데, 보통 main 루틴이나 특수 컨테이너가 전담하게 된다.
나아가, 클래스가 의존성을 해결하려 하지 않고 setter 메서드나 생성자 인수를 통해 의존성을 주입하는 방법을 사용할 수 있다.
2. 확장
오늘날 테스트 주도 개발(TDD)를 통해 시스템을 조정하고 확장하기 쉽게 만든다.
한편 시스템 수준에서는 아키텍처를 사전에 정의해 놓아야 하고, 단순한 아키텍처를 복잡하게 키울 수 있기는 어려워 보인다.
하지만 수명이 짧다는 소프트웨어의 본질로 인해 아키텍처도 관심사를 적절히 분리했다면 점진적인 발전이 가능하다.
3. 테스트 주도 시스템 아키텍처 구축
코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능하다.
이것이 가능해지면 BDUF(Big Design Up Front, 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계)가 필요 없어지고, 아키텍처를 단순한 구조에서 복잡한 구조로 만드는 극적인 변화가 일어날 수 있다.
4. 의사결정 최적화
관심사를 모듈로 분리한 시스템은 기민함을 제공한다. 기민함 덕분에 가능한 마지막 순간까지 결정을 미룰 수 있고, 최적의 결정을 내리기도 쉬워진다.
5. 명백한 가치가 있을 때 표준을 현명하게 사용
표준을 사용하면 아이디어, 컴포넌트의 재사용이 쉽고 아이디어의 캡슐화와 컴포넌트를 엮는 것도 쉬워진다. 하지만 표준을 만드는 시간 자체가 너무 오래 걸리게 되면 표준을 제정한 목적이 퇴색된다.
6. 시스템은 도메인 특화 언어가 필요
도메인 특화 언어(DSL)은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다.
좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이의 '의사소통 간극'을 줄여준다. 이로 인해 개발자가 적절한 추상화 수준에서 코드 의도를 표현하도록 할 수 있다.
