"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다."
- 레이 오지(Ray Ozzie, 마이크로소프트 최고 기술 책임자 (CTO))
- 시스템은 역시 깨끗해야 한다.
- 깨끗하지 못한 아키텍처는
- 도메인 논리를 흐리며 기민성을 떨어뜨린다.
- 도메인 논리가 흐려지면 제품 품질이 떨어진다. (버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓)
- 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
- 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.
- 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심할 것!
시스템 제작과 시스템 사용을 분리하라
-
제작 (construction)은 사용(use)과 아주 다르다.
- 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.
-
시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다.
- 관심사 분리는 가장 오래되고 가장 중요한 설계 기법 중 하나
- 불행히도 대다수 애플리케이션은 시작 단계라는 관심사를 분리하지 않는다.
-
준비 과정 코드에 런타임 로직이 뒤섞인 예
public Service getService(){ if (service == null) service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까? return service; }- 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluation) 기법
- 이 기법의 장점
- 첫째, 실제 필요할 때가지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다.
- 둘째, 어떤 경우에도 null 포인터를 반환하지 않는다.
- 이 기법의 단점
- getService() 가 MyServiceImpl과 생성자 인수에 명시적으로 의존한다.
- 런타임 로직에서 MyServiceImpl 객체를 전혀 사용하지 않더라도 의존성을 해결하지 않으면 컴파일이 안된다.
- MyServiceImpl 이 무거운 객체라면 단위 테스트에서 getService 메서드를 호출하기 전에 적절한 테스트 전용 객체(Test Double 또는 Mock Object)를 service 필드에 할당해야 한다.
- 일반 런타임 로직에 객체 생성 로직을 섞어놓은 탓에 (service 가 null인 경로와 null이 아닌 경로 등) 모든 실행 경로도 테스트해야 한다. (책임이 둘 = 메서드가 작업을 둘 이상 수행 = SRP 위반)
- MyServiceImpl이 모든 상황에 적합한 객체인지 모른다는 사실이 가장 큰 우려.
- getService 메서드를 포함한 클래스가 전체 문맥을 알 필요가 있는지?
- 어떤 객체를 사용할지 알 수 있는지?
- 현실적으로 한 객체 유형이 모든 문맥에 적합할 가능성이 있는지?
-
체계적이고 탄탄한 시스템을 만들고 싶다면 모듈성을 깨서는 절대로 안된다.
-
객체를 생성하거나 의존성을 연결할 때도 마찬가지
- 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.
- 주요 의존성을 해소하기 위한 방식 (즉, 전반적이며 일관적인 방식)도 필요.
Main 에서 생성 분리
-
시스템 생성과 시스템 사용을 분리하는 방법 중 하나
-
생성과 관련한 코드는 모두 main이나 main을 호출하는 모듈로 옮기고 나머지 시스템은 모든 객체가 생성되고 모든 의존성이 연결되었다고 가정
- 제어 흐름
- main 함수에서 시스템에 필요한 객체 생성 → application으로 넘김
- application은 객체를 사용할 뿐 main이나 객체가 생성되는 과정은 전혀 모른다.
- 모든 객체가 적절히 생성되었다고 가정
- 제어 흐름
팩토리
- 객체가 생성되는 시점을 application이 결정할 필요도 생긴다.
- abstract factory 패턴을 사용하면 객체 생성 시점은 application이 결정하지만 객체 생성 코드는 application이 알지 못한다.
- 모든 의존성이 main에서 OrderProcessing Application으로 향한다.
- 즉, OrderProcessing Application은 LineItem이 생성되는 구체적인 방법을 모른다.
- 방법은 LineItemFactoryImplementation이 알고 있음.
- OrderProcessing Application은 LineItem instance가 생성되는 시점을 완벽히 통제하며, 필요하다면 OrderProcessing App에서만 사용하는 생성자 인수도 넘길 수 있음
의존성 주입
-
의존성 주입(DI, Dependency Injection) : 제어의 역전(IoC, Inversion of Control) 기법을 의존성 관리에 적용한 매커니즘
-
IoC에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘김
- 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙(SRP, Single Responsibility Principle)을 지키게 된다.
- 의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않음
- 대신에, 책임을 다른 '전담' 메커니즘에 넘겨야 한다. (제어의 역전)
- 초기 설정은 시스템 전체에서 필요하므로 '책임질' 매커니즘으로 'main' 루틴이나 특수 컨테이너를 사용
-
JNDI 검색은 의존성 주입을 '부분적으로' 구현한 기능
// 객체는 디렉터리 서버에 이름을 제공하고 그 이름에 일치하는 서비스를 요청한다. MyService myService = (MyService) (jndiContext.lookup("NameOfMyService"));- 호출하는 객체는 실제로 반환되는 객체의 유형을 제어하지 않음 (반환되는 객체가 적절한 인터페이스를 구현하는 한)
- 대신 호출하는 객체는 의존성을 능동적으로 해결한다.
-
진정한 의존성 주입은 클래스가 의존성을 해결하려 시도하지 않는다. (클래스는 완전히 수동적)
- 대신에 의존성을 주입하는 방법으로 설정자(setter) 메서드나 생성자 인수를 제공한다. (혹은 둘 다 제공)
- DI 컨테이너는 (요청이 들어올 때마다) 필요한 객체의 인스턴스를 만든 후 생성자 인수나 설정자 메서드를 사용해 의존성을 설정한다.
- 실제로 생성되는 객체 유형은 설정 파일에서 지정하거나 특수 생성 모듈에서 코드로 명시한다.
-
스프링 프레임워크는 Java DI Container를 제공한다.
- 객체 사이 의존성은 XML 파일에 정의한다. 자바 코드에서는 이름으로 특정한 객체를 요청한다.
-
DI를 사용하더라도 초기화 지연 가능
- 대다수 DI 컨테이너는 필요할 때까지는 객체를 생성하지 않고, 대부분은 계산 지연이나 비슷한 최적화에 쓸 수 있도록 팩토리를 호출하거나 프록시를 생성하는 방법을 제공
- 계산 지연 기법이나 이와 유사한 최적화 기법에서 이런 매커니즘을 사용
확장
- '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다.
- 반복적이고 점진적인 애자일 방식
- 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다.
- 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
- 테스트 주도 개발(TDD, Test-driven Development), 리팩터링, (TDD와 리팩터링으로 얻어지는) 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만듦.
- 시스템 수준(아키텍처)은 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실.
- 현실은 현실이지만... 소프트웨어 시스템은 물리적인 시스템과 달리 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전한 수 있다.
자바에서의 aspect
자바 프록시 (proxy)
-
단순한 상황에 적합
-
개별 객체나 클래스에서 메서드 호출을 감싸는 경우
-
JDK에서 제공하는 동적 프록시는 인터페이스만 지원 (클래스 proxy는 CGLIB, ASM, Javassist 등과 같은 바이트 코드 처리 라이브러리 필요)
-
JDK 제공 proxy 예제
import java.util.* // 은행 추상화 public interface Bank { Collection<Account> getAccounts(); void setAccounts(Collection<Account> accounts); }import java.util.* // 추상화를 위한 POJO 구현 public interface BankImpl implements Bank { private List<Account> accounts; public Collection<Account> getAccounts(){ return accounts; } public void setAccounts(Collection<Account> accounts) { this.accounts = new ArrayList<Account>(); for (Account account : accounts) { this.accounts.add(account); } } }import java.lang.reflect.*; import java.util.*; // 프록시 API가 필요한 "InvocationHandler" public class BankProxyHandler implements InvocationHandler { private Bank bank; public BankProxyHandler (Bank bank) { this.bank = bank; } // InvocationHandler에 정의된 메서드 (invoke) public Object invoke (Object proxy, Method method, Object[] args) throws Throwable { String methodName = method.getName(); if (methodName.equals("getAccounts")) { bank.setAccounts(getAccountsFromDatabase()); return bank.getAccounts(); } else if (methodName.equals("setAccounts")) { bank.setAccounts((Collection<Account>) args[0]); setAccountsToDatabase(bank.getAccounts()); return null; } else { ... } } // 세부사항은 여기에 이어진다. protected Collection<Account> getAccountsFromDatabase() { ... } protected void setAccountsToDatabase(Collection<Account> accounts) { ... } }// 다른 곳에 위치하는 코드 // bank를 BankProxyHandler로 구현 Bank bank = (Bank) Proxy.newProxyInstance( Bank.class.getClassLoader(), new Class[] {Bank.class}, new BankProxyHandler(new BankImpl())); -
프록시로 감쌀 인터페이스 Bank와 비즈니스 논리를 구현하는 POJO BankImpl을 정의
-
프록시 API에는 InvocationHandler를 넘겨줘야 한다.
- 넘긴 InvocationHandler는 프록시에 호출되는 Bank 메서드를 구현하는 데 사용된다.
- BankProxyHandler는 Java Reflection API를 사용해 제네릭스 메서드를 상응하는 BankImpl 메서드로 매핑한다.
-
단순한 예제(라고는 하는데..)이지만 코드가 상당히 많으며 제법 복잡하다.
-
코드의 '양', '크기'는 프록시의 두 가지 단점
- 다시 말하면, 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다.
- (진정한 AOP 해법에 필요한) 시스템 단위로 실행 '지점'을 명시하는 메커니즘도 제공하지 않는다.
순수 자바 AOP 프레임워크
-
Spring AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다.
-
스프링은 비즈니스 논리를 POJO로 구현한다.
- POJO는 엔터프라이즈 프레임워크(그리고 다른 도메인에도) 의존하지 않는다.
- 테스트가 개념적으로 더 쉽고 단순하다.
- 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉬우며 앞으로의 요구사항(미래 스토리)에 맞춰 코드를 보수하고 개선하기 편하다.
-
프로그래머는 설정 파일이나 API를 사용해 필수적인 Application 기반 구조를 구현한다.
- 영속성, 트랜잭션, 보안, 캐시, 장애조치 등과 같은 횡단 관심사도 포함
- 많은 경우 스프링이나 JBoss 라이브러리의 Aspect를 명시한다.
- 이 때, 프레임워크는 사용자가 모르게 프록시나 바이트코드 라이브러리를 사용해 이를 구현한다.
- 이런 선언들이 요청에 따라 주요 객체를 생성하고 서로 연결하는 등 DI 컨테이너의 구체적인 동작을 제어한다.
-
ex) Spring 2.x의 app.xml
- Bank 도메인 객체는 자료 접근자 객체(DAO, Data Accessor Object)로 프록시되었으며, 자료 접근자 객체는 JDBC 드라이버 자료 소스로 프록시되었다.
- 클라이언트는 Bank 객체에서 getAccounts()를 호출한다고 믿지만 실제로는 Bank POJO의 기본 동작을 확장한
중첩 Decorator 객체 집합의 가장 외곽과 통신한다. (필요하다면 트랜잭션, 캐싱 등에도 Decorator를 추가할 수 있다.)
-
EJB3는 XML 설정 파일과 자바 5 애너테이션 기능을 사용해 횡단 관심사를 선언적으로 지원하는 스프링 모델을 따른다. (스프링 프레임워크는 EJB 버전 3를 완전히 뜯어고치는 계기를 제공)
AspectJ aspect
- AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장이다.
- AspectJ는 관점을 분리하는 강력하고 풍부한 도구 집합을 제공하긴 하지만, 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있음
- AspectJ '애너테이션 폼'은 새로운 도구와 새로운 언어라는 부담을 어느 정도 완화한다.
- AspectJ에 대한 내용 확인은 링크로 대체
Intro to AspectJ - baeldung - Spring AOP <-> AspectJ
테스트 주도 시스템 아키텍처 구축
-
aspect로(혹은 유사한 개념으로) 관심사를 분리하는 방식은 그 위력이 막강하다.
- 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면 (즉, 코드 수준에서 아키텍처 관심사를 분리할 수 있다면) 진정한 테스트 주도 아키텍처 구축이 가능해진다.
- BDUF, Big Design Up Front를 추구할 필요도 없음.
- BDUF는 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계하는 기법
↔ 선행 설계 (up-front design)과 혼동하지 않도록 주의
- BDUF는 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계하는 기법
-
프로젝트를 시작할 때는 일반적인 범위, 목표, 일정은 물론이고 결과로 내놓을 시스템의 일반적인 구조도 생각해야 한다.
+ 변하는 환경에 대체해 진로를 변경할 능력도 유지해야 한다. -
최선의 시스템 구조는 각기 POJO(또는 다른) 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성
-
서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합
-
aspect로 통합된 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있음
도메인을 구현하기 위한 로직과 기반 환경(권한 설정, 보안 구성 등) 구현 로직과의 분리는 결국 도메인 로직을 구현하고 검증하는 데 집중할 수 있는 구조가 유지보수에 유용하다는 것으로 정리하였습니다.
aspect에 대해서는 추가적으로 정리가 필요하겠지만 비즈니스 로직이 특정 환경이나 설정에 의존적이거나 선행이 필요한 상태가 되지 않도록 유의해야겠습니다.
