해당 포스트는 Clean Code의 내용을 참고하여 작성되었습니다.

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

소프트웨어 시스템은 어플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 준비 과정 이후에 이어지는 런타임 로직을 분리해야 한다. 제작과 사용은 아주 다르다. 시작 단계는 모든 어플리케이션이 풀어야 하는 관심사이다. 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법이다.

하나의 클래스내에 준비 과정 코드를 Lazy Initialization으로 구현하고 런타임 로직이 마구 뒤섞여있는 코드를 본 적이 있을 것이다. 이런 시스템 곳곳에 흩어져 있다. 모듈성은 저조하며 중복은 심각하다.

Main 분리

시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 이렇게 되면 제어의 흐름은 따라가기 쉽다. main함수에서 시스템에 필요한 객체를 생성하고 어플리케이션은 이를 사용한다. 즉 어플리케이션은 main이나 객체가 생성되는 과정을 전혀 몰라도 된다.

팩토리

객체가 생성되는 시점을 어플리케이션이 결정해야할 필요도 있다. 이 때는 추상 팩토리 패턴을 사용해 생성하는 코드를 감춘다.

의존성 주입

DI는 IoC기법을 의존성 관리에 적용한 메커니즘이다. 의존성 생성에 대한 책임을 다른 객체에게 맡기므로 SRP를 지키게 된다.

확장

처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다. TDD와 리팩터링으로 얻어지는 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다. 시스템도 동일하다.

관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

횡단 관심사

트랜잭션, 영속성, 보안과 같은 것들은 어떻게 처리를 해야할까? 논리적으로는 독립된 형태이지만 코드 여기저기에 위치하기 쉬운 코드는 어떻게 해야할까? AOP로 해결할 수 있다. AOP에서 aspect라는 모듈 구성 개념은 특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야한다라고 명시한다.

자바 프록시

자바 프록시는 단순한 상황에 적합하다. 개별 객체나 클래스에서 메소드 호출을 감싸는 경우가 좋은 예다. 단순한 value object와 비즈니스 로직을 담는 POJO가 있다고 가정하자. 그렇다면 프록시 API에는 InvocatonHandler를 넘겨줘야 한다. 넘긴 InvocationHandler는 프록시에 호출되는 value object의 메소드를 구현하는데 사용된다. 프록시는 자바 리플렉션 API를 사용해 제네릭스 메소드를 상응하는 POJO 클래스의 메소드로 맵핑한다. 하지만 코드가 많고 복잡한건 단점이다. 바이트 조작 라이브러리를 사용해도 꽤나 어렵다.

순수 자바 AOP 프레임워크

AOP Framework를 통해 위의 단점들을 해결할 수 있다. Spring에서는 POJO로 비즈니스 로직을 작성해 도메인에만 집중할 수 있다.

AspectJ 관점

관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ 언어이다. AspectJ는 관점을 분리하는 강력하고 풍부한 도구 집합을 제공하긴 하지만 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있다. 하지만 최근에 나온 AspectJ Annotation form은 이를 어느정도 완화한다.

관심사의 분리

관심사를 분리하는 방식은 장점이 많다. 어플리케이션 도메인 논리를 POJO로 작성할 수 있다면 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면 진정한 테스트 주도 아키텍처 구축이 가능해진다. 또한 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 관심사를 분리한 POJO 시스템은 기민함을 제공한다. 덕분에 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다.