복잡성은 죽음이다.
개발자에게서 생기를 앗아가며 제품을 계획하고 제작하고 테스트하기 어렵게 만든다.
혼자서 도시의 세세한 사항을 직접 관리하는 것은 불가능하다.
도시는 각 분야를 관리하는 팀이 있어 잘 돌아가는 것이다.
- 수도 관리 팀
- 전력 관리 팀
- 교통 관리 팀
- 기타 등등 팀...
도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다.
큰 그림을 이해하지 못하더라도 개인이 관리하는 구성 요소는 효율적으로 돌아간다.
즉, 각기 다른 구성 요소들이 모여 전체 큰 시스템을 동작시키는 것이다.
하나의 소프트웨어는 하나의 국가처럼 구성한다.
하나의 소프트웨어 모듈은 하나의 도시처럼 구성한다.
각각의 모듈을 깨끗한 코드로 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
즉, 각각의 요소마다 관리하기 깨끗한 코드로 작성하면 효율적인 시스템을 만들 수 있다.
제작과 사용은 서로 다른 관심사이다.
다시 한번 말한다. 제작 과 사용 은 서로 다른 관심사이다.
소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야한다.
- 준비 과정 : 애플리케이션 객체를 제작하고 의존성을 연결하는 과정
- 런타임 로직 : 준비 과정 이후에 이어지는 작업
시작 단계는 모든 애플리케이션 관심사를 분리하는 것이다.
관심사가 분리되지 않은 코드
public class MyServiceImpl extends Service {
private int a;
private int b;
public MyServiceImpl(int a, int b) {
this.a = a;
this.b = b;
}
}public class SampleClass {
private Service service;
public Service getService() { // 인수가 있을 수도 있고 없을 수도 있다.
if (service == null) {
// MyServiceImpl 객체를 생성하기 전에 인수를 만들 수도 있고 안 만들 수도 있다.
service = new MyServiceImpl(...); // 객체를 생성하는 것은 모든 상황에 적합한 기본값일까?
}
return service;
}
}- 위 코드는
늦은 초기화 방식기법을 사용하고 있다. nullPointer를 반환하지 않고 한 개의 객체만 사용한다는 장점이 있다.
일부러 싱글톤 패턴으로 정의하지 않았다.
이유 :
* 늦은 초기화 방식이지 싱글톤 패턴이라는 명시는 없었다.
* 후에 공부하다 보면 싱글톤 패턴을 가리키고 있지 않을 것을 알 수 있다.
* 또한, 싱글톤 패턴으로 인식하면 아래에서 맞지 않는 내용이 있다.
하지만, 이 같은 코드로 인해 발생하는 문제가 여럿 있다.
getService() 메스드가 의존적인 메서드가 되는 문제
MyServiceImpl객체를 직접 생성하므로 해당 클래스에 의존적이다.- 객체를 생성함에 있어 인수도 사용하므로 생성자 인수에 명시적으로 의존한다.
getService()호출시 인수를 받아야 되는 경우getService()호출시 인수를 받지 않는 경우는 메서드 내에서 인수 생성- 어떤 경우라도 메서드가 생성자 인수를 명시적으로 의존한다.
- 실제 프로그램의 실행 과정인 런타임 로직에서
MyServiceImpl객체를 사용하지 않더라도
코드상에서 의존성 문제를 해결하지 않으면 컴파일 에러가 발생하며 런타임도 불가능해진다. - 결국,
getService()메서드 외에도 전체 문맥을 알아야 되는 문제가 생긴다.
쉽게 설명하면, 객체를 직접 생성하는 것은
그 객체가 런타임시에 실제로 사용되든 안하든 의존성 관계를 처리해줘야 하고
객체를 생성하는 데 있어 필요한 인수들까지 관리를 해야한다.
그렇기에 전체적인 맥락, 흐름등을 파악해야하는 문제가 발생한다.
테스트에서 문제
MyServiceImpl이 무거운 객체이며 단위 테스트를 한다고 가정한다.- 메서드를 테스트하기 전에 적절한
Service객체를service필드에 할당해야 한다. - 즉,
MyServiceImpl에 속한serive필드의 값을 넣어주는 작업을 매번 해야 한다. - 더불어 일반 런타임 로직에다 객체 생성 로직을 섞어놓은 탓에 모든 실행 경로도 테스트해야 한다.
SRP 원칙을 깨는 문제
- 객체를 의존하면서 관리해야 하는 책임
- 객체를 직접 생성하는 책임
- 2가지 책임이 따르기에 작게나마 SRP 단일 책임 원칙을 깨진다.
모든 상황에 적합한 객체인지 모른다는 문제
- 어떤 요구 사항, 기능에서는
MyServiceImpl객체가 아닌 다른 객체가 필요하다. - 즉, 다른 Service를 구현하는 객체로 바꿔야 할 경우가 있다.
- 하지만 직접적으로
new MyServiceImpl()를 생성해서 사용한다. - 이같은 코드가 100개의 파일에 있을 경우 100개의 파일 전부를 수정해야 하는 문제가 있다.
초기화 기법을 한 번 정도 사용한다면 별로 심각한 문제가 아니다.
하지만 많은 애플리케이션이 이처럼 좀스러운 설정 기법을 수시로 사용한다.
그래서 전반적인 설정 방식이 애플리케이션 곳곳에 흩어져 있다.
모듈성은 저조하며 대개 중복이 심하다.
체계적이고 탄탄한 시스템을 만들고 싶다면
흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대 안 된다.
객체를 생성하거나 의존성을 연결할 때도 마찬가지이다.
설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.
또한 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적인 방식도 필요하다.
시스템
생성과 시스템사용을 분리하는 한 가지 방법
- main
/main이 호출하는 모듈 : 객체의 생성과 관련된 코드를 작성 - 나머지 시스템 : 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정하여 코드 작성
- 즉,
main에서 객체를 생성하고 그 외에서는 객체를 생성하지 않고 사용만 하자 - 필자의 생각 : 이 과정에서 DI(의존성 주입) 를 통해 시스템에 유연성을 더해준다.
제어 흐름
main에서 시스템에 필요한 객체를 생성한 후 이를애플리케이션에 넘긴다.애플리케이션은 단지, 의존 받은 객체를 사용할 뿐이다.
제어 흐름 특징
main과애플리케이션사이에 표시된 의존성 화살표의 방향의 주목하자- 모든 화살표가
main에서애플리케이션을 향한다. - 즉,
애플리케이션은main에서 객체가 생성되는 과정을 전혀 모른다는 뜻이다. - 애플리케이션은 단지 모든 객체가 적절히 생성되었다고 가정하고 의존받아 동작할 뿐이다.
main이 아니더라도애플리케이션은 독릭접으로 객체를 의존받아 사용할 수 있다.
때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 있다.
LineItem 인스턴스를 생성해 Order에 추가하는 시스템이다.
여기서 OrderProcessing이 객체를 생성하는 애플리케이션이다.
제어 흐름
- 이 부분은 abstarct-factoty 패턴을 공부해보고 정리해야 할 것 같습니다.
- 현재 내가 이해한 abstarct-factoty 패턴 :
- 컴퓨터 생산 -> 모니터, 키보드, 본체 등등이 있음
- Samsung이나 LG에서 생산한다면, 전부 다 자신의 부품으로 만들어야 함
- 그러나 일반적인 팩토리 패턴을 이용하면, 각각의 부품마다 회사를 의존해야함
- 그러지 말고, 애초에 팩토리 자체도 추상화 시켜 LG팩토리/Samsung 팩토리로 만들자
- 그렇게 만들면 자신의 회사만 생성하게끔 만들면 되지 않냐?
- 참고
제어 흐름 특징
- 의존성이
main에서OrderProcessing으로 향한다. - 즉,
OrderProcessing은LineItem이 생성되는 구체적인 방법을 모른다. - 구체적인 생성 방법은
main의LineItemFactoryImplementation가 안다. - 그럼에도
OrderProcessing은LineItem인스턴스가 생성 시점을 완벽하게 통제한다. - 필요하다면
OrderProcessing에서만 사용하는 생성자 인수도 넘길 수 있다. - 이유로는
ABSTRACT FACTORY 패턴을 사용하기 때문이다.LineItem을 생성하는 시점은OrderProcessing이 결정하지만
LineItem을 생성하는 코드는OrderProcessing이 모른다.ABSTRACT FACTORY 패턴이란? :
쉽게 말하면 코드를 생성하는 factory 또한 추상적으로 관리하는 기법
참고
사용과제작을 분리하는 가장 강력한 메커니즘 중 하나가 DI(의존성 주입)이다.
DI(의존성 주입)
제어의 역전 기법(IoC)을의존성 관리에 적용한 매커니즘이다.- 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.
- 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙을 가지게 된다.(관리 책임)
- 의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않는다.
- 대신에
인스턴스 생성 책임을 다른 '전담 매커니즘'에 넘겨야 하므로 제어를 역전한다. 스프링 프레임워크에서는ApplicationContext나BeanFactory에 책임을 넘긴다.- 초기 설정은 시스템 전체에서 필요하므로 대개
main 루틴이나특수 컨테이너를 사용한다.
예시- JNDI 검색
JNDI 검색은 의존성 주입을 '부분적으로' 구현한 기능이다.
객체는 디렉터리 서버에 이름을 제공하고 그 이름에 일치하는 서비스를 요청한다.
MyService myService = (MyService)(jndiContext.lookup("NameOfMyService")); - 호출하는 객체는 실제로 반환되는 객체의 유형을 제어하지 않는다.
- 쉽게 설명하면 어떤 클래스가 올지에 대한 제어를 하지 못한다는 의미이다.
- 호출하는 객체는 단지 반환된 객체를 의존하여 사용하기만 할 뿐이다.
- 그렇기에 다른 말로, 호출하는 객체는 객체를 생성하는 코드에 관여하지 않는다는 것이다.
- 호출하는 객체는 의존성을 능동적으로 해결한다.
- 어떤 객체로 리턴되는지는 모르지만 유형에 맞다면 객체에 알맞는 로직을 실행한다.
- 추가로, 어떠한 객첵라도 메서드가 동일하게 존재해 완벽히 사용할 수 있도록 구현해야한다.
- 만약, 어떤 객체에는 존재하지만 다른 객체에 존재하지 않는다면 설계를 잘못했을 가능성이 크다.
public Sample {
MyService myService;
public Sample(MyService myService) {
this.myService = myService;
}
public setMyService(MyService myService) {
this.myService = myService;
}
}진정한 의존성 주입은 여기서 한 걸음 더 나간다.
- 클래스는 수동적이기 때문에 클래스가 의존성을 해결하려 시도하지 않게끔 만들어야 한다.
- 한 걸음 나아간 방법 :
- 객체 사용 클래스 :
setter 함수나생성자에 인수를 제공 - DI 컨테이너 : 객체를 생성하고
setter 함수나생성자를 사용해 의존성을 설정 - 실제로 생성되는 객체 유형은 실제 파일에서 지정하거나 특수 생성 모듈에서 코드로 명시한다.
- 객체 사용 클래스 :
- 특히, 스프링 프레임워크는 가장 널리 알려진 자바
DI 컨테이너를 제공한다.- 객체 사이의 의존성은
XML 파일에 정의한다. - 자바 코드에서는 이름으로 특정한 객체를 요청한다.
- 객체 사이의 의존성은
그렇다면, 의존성 주입을 사용하면 초기화 지연의 장점은 포기해야 하는 걸까?
- 초기화 지연 기법은 의존성 주입을 사용하더라도 때론 여전히 유용하다.
- 대대수
DI 컨테이너는 필요할 때 까지 객체를 생성하지 않는다. 계산 지연이나최적화에 쓸 수 있도록 팩토리를 호출하거나 프록시를 생성하는 방법을 제공한다.- 즉,
계산 지연 기법이나 이와 유사한최적화 기법에서 의존성 주입 메커니즘을 사용할 수 있다.
처음부터 올바르게시스템을 만들 수 있다는 믿음은 미신이다.
오늘은 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다.
내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
이것이 반복적이고 점진적인 애자일 방식의 핵심이다.
TDD, 리팩토링, 깨끗한 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.
하지만, '소프트웨어 시스템 아키텍처'는 사전 계획이 필요하다.
단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실은 정확하다.
소프트웨어 시스템은 수명이 짧다는 본질로 인해 아키텍처의 점진적인 발전이 가능하다.
관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.
예시 - 관심사를 적절히 분리하지 못하는 아키텍처
잠깐!! 예시 코드의 목적은 얼마나 강하게 결합되었는지를 말해주기 위함입니다.
그렇기에 코드에 대한 세세한 설명 및 분석은 넘어가고 요점만 정리해보겠습니다.
EJB1과 EJB2 아키텍처는 관심사를 적절히 분리하지 못했기에 유기적인 성장이 어려웠다.
영속적으로 저장될 Bank 클래스에 필요한 엔티티 빈을 살펴보자.
엔티티 빈은 관계형 자료, 즉 테이블 행을 표현하는 객체로, 메모리에 상주한다.
먼저, 클라이언트가 사용할 지역 인터페이스나 원격 인터페이스를 정의해야 한다.
아래는 가능한 지역 인터페이스다.
Bank EJB용 EJB2 지역 인터페이스
package com.example.banking;
import java.util.Collections;
import javax.ejb.*;
public interface BankLocal extends java.ejb.EJBLocalObject {
String getStreetAddr1() throws EJBException;
String getStreetAddr2() throws EJBException;
String getCity() throws EJBException;
String getState() throws EJBException;
String getZipCode() throws EJBException;
void setStreetAddr1(String street1) throws EJBException;
void setStreetAddr2(String street2) throws EJBException;
void setCity(String city) throws EJBException;
void setState(String state) throws EJBException;
void setZipCode(String zip) throws EJBException;
Collection getAccounts() throws EJBException;
void setAccounts(Collection accounts) throws EJBException;
void addAccount(AccountDTO accountDTO) throws EJBException;
}- 열거하는 속성은 Bank 주소, 은행이 소유하는 계좌다.
- 각 계좌 정보는 Account EJB로 처리한다.
아래는 위의 인터페이스를 구현한 Bank 빈에 대한 구현 클래스다.
상응하는 EJB2 엔티티 빈 구현
/* Code 2-2(Listing 11-2): The corresponding EJB2 Entity Bean Implementation */
package com.example.banking;
import java.util.Collections;
import javax.ejb.*;
public abstract class Bank implements javax.ejb.EntityBean {
// Business logic...
public abstract String getStreetAddr1();
public abstract String getStreetAddr2();
public abstract String getCity();
public abstract String getState();
public abstract String getZipCode();
public abstract void setStreetAddr1(String street1);
public abstract void setStreetAddr2(String street2);
public abstract void setCity(String city);
public abstract void setState(String state);
public abstract void setZipCode(String zip);
public abstract Collection getAccounts();
public abstract void setAccounts(Collection accounts);
public void addAccount(AccountDTO accountDTO) {
InitialContext context = new InitialContext();
AccountHomeLocal accountHome = context.lookup("AccountHomeLocal");
AccountLocal account = accountHome.create(accountDTO);
Collection accounts = getAccounts();
accounts.add(account);
}
// EJB container logic
public abstract void setId(Integer id);
public abstract Integer getId();
public Integer ejbCreate(Integer id) { ... }
public void ejbPostCreate(Integer id) { ... }
// The rest had to be implemented but were usually empty:
public void setEntityContext(EntityContext ctx) {}
public void unsetEntityContext() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbLoad() {}
public void ejbStore() {}
public void ejbRemove() {}
}- 객체를 생성하는 팩토리인 LocalHome 인터페이스는 생략했다.
- 기타 Bank 탐색(질의) 메서드도 생략했다.
문제점 :
- 비지니스 로직이 EJB2 컨테이너에 타이트하게 연결되어 있다.
- 테스트를 하려면 컨테이너를 흉내 내거나 EJB와 테스트를 실제 서버에 배치해야하므로 어렵다.
- 실제로 사용되지 않을 테스트 객체의 작성을 위해 mock 객체를 만드는 데에도 무의미한 노력이 많이 든다.
- Entity를 만들기 위해 컨테이너 타입을 subclass하고 필요한 lifecycle 메서드를 구현해야 한다.
- EJB2 구조가 아닌 다른 구조에서 재사용할 수 없는 컴포넌트를 작성해야 한다.
- 상속도 불가능하며 쓸데없는 DTO(Data Transfer Object)를 작성하게 만든다.
- OOP 또한 등한시되고 있다.
- 그래서 EJB2 코드는 프레임워크 밖에서 재사용하기란 사실상 불가능하다.
- 결국 EJB 아키텍처는 객체 지향 프로그래밍이라는 뿌리조차 흔들리는 결과를 만들게 되었다.
- EJB2 아키텍처는 일부 영역에서 관심사를 거의 완벽하게 분리한다.
- 트랜잭션, 보안, 일부 영속적인 동작은 소스 코드가 아니라 배치 기술자에서 정의한다.
- 영속성과 같은 관심사는 모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다.
- 특정 DBMS나 독자적인 파일을 사용하고,
테이블과 열은 같은 명명 관례를 따르며,
트랜잭션 의미가 일관적이면 더욱 바람직하다.
- 특정 DBMS나 독자적인 파일을 사용하고,
- 사실 EJB 아키텍처가 영속성, 보안, 트랜잭션을 처리하는 방식은 관점 지향 프로그래민(AOP)을 예견했다고 보인다.
자바에서 사용하는 관점 혹은 관점과 유사한 메커니즘 3개를 살펴보자
- 자바 프록시
- AOP
- AspectJ
자바 프록시(JDK Proxy)는 단순한 상황에 적합하다.
개별 객체나 클래스에서 메서드 호출을 감싸는 경우가 좋은 예다.
프록시에 대한 설명
그리고 프록시와 관점의 관계에 대해서 필자는 잘 모릅니다.
그렇기 때문에 이 부분은 추후에 공부를 하고 나서 다시 정리를 해보겠습니다.
프록시에 대한 설명 - 우아한테크코스
프록시에 대한 설명 - dreamchaser3님의 블로그
잠깐!
일반적으로 JDK에서 제공하는 '동적 프록시'는 인터페이스만 지원한다.
'클래스 프록시'를 사용하려면 GGLIB, ASM, javascrist 등과 같은
바이트코드 처리 라이브러리가 필요하다.
아래는 Bank 애플리케이션에서 JDK 프록시를 사용해 영속성을 지원하는 예제이다.
여기서는 계좌 목록을 가져오고 설정하는 메서드만 소개한다.
JDK 프록시 예제
// Bank.java (패키지 이름을 감춘다)
import java.utils.*;
// 은행 추상화
public interface Bank {
Collection<Account> getAccounts();
void setAccounts(Collection<Account> accounts);
}// BankImpl.java
import java.utils.*;
// 추상화를 위한 POJO("Plain Old Java Object") 구현
public class 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);
}
}
}// BankProxyHandler.java
import java.lang.reflect.*;
import java.util.*;
// 프록시 API가 필요한 "InvocationHandler"
public class BankProxyHandler implements InvocationHandler {
private Bank bank;
public BankHandler (Bank bank) {
this.bank = bank;
}
// InvocationHandler에 정의된 메서드
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 bank = (Bank) Proxy.newProxyInstance(
Bank.class.getClassLoader(),
new Class[] { Bank.class },
new BankProxyHandler(new BankImpl())
);위 코드에 대한 간략한 설명은 아래와 같다.
Java Proxy API를 위한Bank인터페이스를 작성한다.Bank인터페이스를 구횬한BankImpl(POJO aka Plane Old Java Object)를 구현한다.
여기에는 순수한 데이터만 들어가며 비지니스 로직은 포함되지 않는다.(모델과 로직의 분리)- InvocationHandler를 구현하는 BankProxyHandler를 작성한다.
프록시 API에는 InvocationHandler를 넘겨줘야 한다.
InvocationHandler는Java Reflection API를 이용해
Bank인터페이스를 구현하는 객체들의 메서드콜을 가로챌 수 있으며 로직을 추가할 수 있다.
본 예제에서 비지니스 로직(persistant stack logic)은 이 곳에 들어간다. - 마지막으로, 코드의 마지막 블럭과 같이
BankImpl객체를BankProxyHandler에 할당,
Bank인터페이스를 이용해 프록시된 인터페이스를 사용해 모델과 로직이 분리된 코드를 작성할 수 있다.
이로써 모델과 로직의 분리를 이뤄낸 코드를 작성할 수 있게 되었다.
하지만, 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다!!
- 단순한 예제지만 코드가 상당히 많으며 복잡하다.
- 바이트 조작 라이브러리를 사용하더라도 만만찮게 어렵다.
코드의 '양'과 '크기'는 프록시의 2가지 단점이다.
다시 말해 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다!
또한, 시스템 단위로 실행 '지점'을 명시하는 Advice 메커니즘도 제공하지 않는다.
메서드 가로채기/프록시를 통한 감싸기등도 AOP를 구현하는 기법이다.
흔히 AOP를 구현하는 기법과 AOP자체를 혼동하는 경우가 대부분이다.
AOP의 진정한 가치는 시스템 동작을 간결하고 모듈화된 방식으로 명시하는 능력이다.
다행스럽게도 대부분의 프록시 코드는 판박이라 도구로 자동화할 수 있다.
순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 자바 프레임워크는
내부적으로 프록시를 사용하고 이를 자동화한 프레임워크이다.
그렇기에 순수 자바 관점을 구현하는 프레임워크를 이용한다면,
프록시에서 발생하는 코드의 복잡성을 해결하고 깨끗한 코드를 작성할 수 있게 도와준다.
예를 들자면 스프링은 비즈니스 논리를 POJO로 작성해 도메인에 초점을 맞추게 해준다.
또한, 엔터프라이즈 프레임워크에 그리고 다른 도메인에도 의존하지 않는다.
따라서 테스트가 개념적으로 더 쉽고 간단해지며
상대적으로 단순하기 때문에 사용자 스토리를 올바르게 구현하기 쉬우며
미래 스토리에 맞춰 코드를 보수하고 개선하기 편하다는 장점이 있다.
프로그래머는 설정 파일이나 API를 사용해 필수적인 애플리케이션 기반 구조를 구현한다.
여기에는 영속성, 트랜잭션, 보안, 캐시, 장애조치등과 같은 횡단 관심사도 포함된다.
이때 프레임워크는 사용자가 모르게 프록시나 바이트코드 라이브러리를 사용해 구현한다.
이런 선언들이 요청에 따라 주요 객체를 생성하고 서로 연결하는 등
DI 컨테이너의 구체적인 동작을 제어한다.
스프링 V2.X 설정 파일 app.xml
/* Code 3-2(Listing 11-4): Spring 2.X configuration file */
<beans>
...
<bean id="appDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close"
p:driverClassName="com.mysql.jdbc.Driver"
p:url="jdbc:mysql://localhost:3306/mydb"
p:username="me"/>
<bean id="bankDataAccessObject"
class="com.example.banking.persistence.BankDataAccessObject"
p:dataSource-ref="appDataSource"/>
<bean id="bank"
class="com.example.banking.model.Bank"
p:dataAccessObject-ref="bankDataAccessObject"/>
...
</beans>각 빈(bean)은 중첩된 러시아 인형의 일부분과 같다.
Bank 도메인 객체는 '자료 접근자 객체(DAO)'로 프록시 되었으며,
자료 접근자 객체는 JDBC 드라이버 자료 소스로 프록시되었다.
클라이언트는 Bank객체에서 getAccount()를 호출한다고 믿지만,
실제로는 Bank POJO의 기본 동작을 확장한 중첩 DECORATOR 객체 집합의 가장 외곽과 통신한다.
애플리케이션에서 DI 컨테이너에게
XML 파일에 명시된 시스템 내 최상위 객체를 요청하려면 다음 코드가 필요하다.
/* Code 3-3: Code 3-2의 활용법 */
XmlBeanFactory bf = new XmlBeanFactory(new ClassPathResource("app.xml", getClass()));
Bank bank = (Bank) bf.getBean("bank");스프링 관련 자바 코드가 거의 필요 없으므로 애플리케이션은 사실상 스프링과 독립적이다.
즉, EJB2 시스템이 지녔던 강한 결합이라는 문제가 모두 사라진다.
XML은 장황하고 읽기 어렵다는 문제가 있음에도 불구하고,
이런 설정 파일에 명시된 '정책'이 겉으로 보이지 않지만
자동으로 생성되는 프록시나 관점 논리보다는 단순하다.
관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ 언어이다.
AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장이다.
AspectJ는 AOP를 실현하기 위한 full-featured tool이라 일컬어진다.
80~90%의 경우에는 Spring AOP와 JBoss AOP로도 충분하지만,
AspectJ는 훨씬 강력한 수준의 AOP를 지원한다.
다만 이를 사용하기 위해 새로운 툴, 언어 구조, 관습적인 코드를 익혀야 한다는 단점도 존재한다.
(최근 소개된 "annotation-form AspectJ"로 인해 적용에 필요한 노력은 많이 줄어들었다고 한다.)
관점 혹은 유사한 개념으로 관심사를 분리하는 방식은 그 위력이 막강하다.
도메인 로직을 코드 수준에서 아키텍처 관심사를 분리할 수 있는 POJO로 작성할 수 있다면,
진정한 테스트 주도 아키텍처 구축이 가능해진다.
그때그때 새로운 기술을 채택해 단순한 아키텍처를 정교한 아키텍처로 점진적으로 키워갈 수 있다.
폭포수 모델과 같은 BDUF(Big Design Up Front)방식은 추구할 필요가 없으며 해롭기까지 하다.
처음에 쏟아 부은 노력을 버리지 않으려는 심리적 조항으로 인해,
그리고 처음 선택한 아키텍처가 향후 사고 방식에 미치는 영향으로 인해,
변경을 쉽사리 수용하지 못하는 탓이 크다.
건축의 물리적인 구조는 극적인 변경이 불가능하기에 BDUF(Big Design Up Front) 방식을 취한다.
소프트웨어 역시 나름대로 형체가 있지만,
소프트웨어 구조가 관점을 효과적으로 분리한다면, 극적인 변화가 경제적으로 가능하다.
다시 말해, '아주 단순하면서도' 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해
결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다는 말이다.
세계 최대 웹사이트들도 고도의 자료 캐싱, 보안, 가상화 등을 이용해
아주 높은 가용성과 성능을 효율적이고도 유연하게 달성했다.
설계가 최대한 분리되어 각 추상화 수준과 범위에서 코드가 적당히 단순하기 때문이다.
그렇다고 '아무 방향 없이' 프로젝트에 뛰어들어도 좋다는 소리는 아니다.
프로젝트를 시작할 때는 일반적인 범위, 목표, 일정은 물론, 결과로 내놓을 시스템의 일반적인 구조도 생각해야한다.
또한, 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지해야한다.
초창기 EJB 아키텍처는 기술을 너무 많이 넣느라 관심사를 제대로 분리하지 못했던 유명한 API 중 하나이다.
설계가 아주 멋진 API조차도 정말 필요하지 않으면 과유불급이다.
좋은 API는 걸리적거리지 않아야 하며 팀이 창의적인 노력을 사용자 스토리에 집중하도록 한다.
그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못한다.
요약
최적의 시스템 구조는 각기 POJO(또는 다른)객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다.
이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다.
이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.
도시든 소프트웨어 프로젝트든, 큰 시스템에서는 한 사람이 모든 결정을 내리기 어렵다.
하지만, 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.
왜냐하면 해당 파트의 책임자(사람이 아닌 모듈화된 컴포넌트)에게 결정권을 분배하기 때문이다.
이 과정에서 결정은 최대한 많은 정보가 모일 때까지 미루는 것이 좋다.
너무 일찍 결정하면 고객 피드백을 모으고, 프로젝트를 고민하고, 구현 방안을 탐험할 기회가 사라진다.
우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다.
게으르거나 무책임해서가 아니고 최대한 정보를 모아 최선의 결정을 내리기 위해서다.
성급한 결정은 불충분한 지식으로 내린 결정인 것을 명심하자.
관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다.
이런 기민함 덕택에 최신 시점에 최적의 결정을 내리기가 쉬워진다.
또한 결정의 복잡성도 줄어든다.
EJB2는 단지 표준이라는 이유만으로 많은 팀이 사용했다.
가볍고 간단한 설계로 충분했을 프로젝트에서도 EJB2를 채택했다.
그 결과 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례가 많이 등장했다.
즉, 표준에 심취해 고객을 위한 가치 창출이라는 목표를 잃어 버렸다.
표준은
아이디어와 컴포넌트의 재사용, 관련 전문가 채용, 좋은 아이디어의 캡슐화, 컴포넌트들의 연결을 도와 준다.
하지만, 종종 표준을 만드는 데에 드는 시간은 납품 기한을 맞추기 어렵게 만들고,
혹은 최초에 제공하려던 기능과 동떨어지게 되기도 한다.
그렇기에 명백한 가치가 있을 때 표준을 현명하게 사용하자.
소프트웨어 분야에서 최근 들어 DSL(Domain-Specific Language)이 새롭게 조명 받기 시작했다.
DSL은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다.
DSL로 짠 코드는 필수적인 정보를 명료하고 정확하게 전달하는 어휘, 관용구, 패턴이 풍부하기에
도메인 전문가가 작성한 구조적인 산문처럼 읽히게 해준다는 장점이 있다.
애자일 기법이 팀과 프로젝트 이해 관계자 사이에 의사소통 간극을 주여주듯이
도메인 전문가가 사용하는 언어로 도메인 논리를 구현하면 도메인을 잘못 구현할 가능성이 줄어든다.
또한, 좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 '의사소통 간극'을 줄여준다.
DSL을 효율적으로 사용한다면 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올려주며
그에 따라 개발자가 적절한 추상화 수준에서 코드 의도를 표현할 수 있게 해준다.
도메인 특화 언어(DSL)를 사용하면
고차원 정책에서 저차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다.
시스템 역시 개끗해야 한다.
깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다.
도메인 논리가 흐려지면 제품 품질이 떨어진다.
버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다.
기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
모든 추상화 단계에서 의도는 명확히 표현해야한다.
그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야한다.
시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.