복잡함을 해결하려는 도전

제거될 수 없는 근본적인 복잡함

• 근본적으로 엔터프라이즈 개발에 나타나는 복잡함의 원인은 제거 대상이 아니다. 대신 그 복잡함을 효과적으로 상대할 수 있는 기법이 필요하다.
• 문제는 비즈니스 로직의 복잡함을 효과적으로 다루기 위한 방법과 기술적인 복잡함을 효과적으로 처리하는 데 적용되는 방법이 다르다는 점이다. 따라서, 가장 먼저 해야할 일은 성격이 다른 두 가지 복잡함을 분리해 내는 것이다.

실패한 해결책: EJB

• EJB는 일부 기술적인 복잡함을 덜어주려는 시도를 하다가 오히려 더 큰 복잡함을 추가하는 실수를 하였다. 가장 치명적인 건, EJB라는 틀 안에서 자바 코드를 만들게 강제함으로써 자바 언어가 원래 갖고 있던 장점마저 잃어버렸다는 사실이다.

비침투적인 방식을 통한 효과적인 해결책: Spring

• 스프링은 EJB의 실패를 교훈으로 삼아서 출발했다.
• EJB의 처음 목표와 마찬가지로 기술적인 복잡함을 애플리케이션 핵심 로직의 복잡함에서 제거하는 데 목표를 뒀다.

  침투적인 기술: EJB 처럼 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등작하는 경우를 침투적인 기술이라고 한다.
  
  비침투적인 기술: 기술의 적용 사실이 코드에 직접 반영되지 않는 특징이 있다. 어딘가에는 기술의 적용에 따라 필요한 작업을 해줘야 하겠지만, 애플리케이션 코드 여기저기에 불쑥 등장하거나, 코드의 설계나 구현방식을 제한하지 않는다는 게 비침투적인 기술의 특징이다.

• 스프링은 비침투적인 기술이라는 전략을 택하여 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있다.

복잡함을 상대하는 스프링 전략

기술적인 복잡함을 상대하는 전략

1. 첫번째 문제: 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다.
   • 스프링의 해결책은 서비스 추상화이다.
   • ex. 트랜잭션 추상화, OXM 추상화 등
   • 기술적인 복잡함은 일단 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부기술에 독립적인 접근 인터페이스를 제공한다.
2. 두번째 문제: 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
   • 기술과 비즈니스 로직의 혼재로 발생하는 복잡함을 해결하기 위한 스프링의 접근방법은 AOP이다.
   • ex. 트랜잭션, 보안적용, 로깅, 감사(audit) 등

비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략

• 예전에는 비즈니스 로직의 상당 부분을 DB에 두는 것이 유행이었다. 하지만 엔터프라이즈 규모가 커지고, 복잡함이 증가하면서 DB에 비즈니스 로직을 두는 건 매우 불편할 뿐더러 위험한 일이라고 여겨지기 시작했다.
• 확장하기 힘들고 확장하더라도 비용이 많이 드는 공유자원인 DB에 커단란 부담을 주는 것이 문제고, 데이터 액세스 중심으로 로직을 다루면 개발과 유지보수는 물론이고 테스트도 매우 어렵다.
• 따라서 엔터프라이즈 시스템 개발에서 비즈니스 로직은 애플리케이션 안에서 처리하도록 만드는 추세다.
• DB는 단지 데이터의 영구적인 저장과 복잡한 조건을 가진 검색과 같은 자체적으로 특화된 기능에만 활용하고, 데이터를 분석하고 가공하는 그에 따라 로직을 처리하는 부분은 확장하기 쉽고, 비용도 싼 애플리케이션 서버 쪽으로 이동하는 것이다.

핵심도구: 객체지향과 DI

• 스프링의 모토는 '기본으로 돌아가자' 이다.
• 자바의 기본인 객체지향에 충실한 설계가 가능하도록 단순한 오브젝트를 개발할 수 있고, 객체지향의 설계 기법을 잘 적용할 수 있는 구조를 만들기 위해 DI 같은 유용한 기술을 편하게 적용하도록 도와주는 것이 스프링의 기본 전략이다.
• 서비스 추상화, 템플릿/콜백, AOP와 같은 스프링의 기술은 DI없이 존재할 수 없는 것들이다.

POJO 프로그래밍

'분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다' 는 것이 스프링의 가장 강력한 특징과 목표이다.

스프링의 핵심: POJO

• Spring application은 POJO를 이용해서 만든 애플리케이션 코드와, POJO가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계 정보로 구분된다.
• 스프링의 주요 기술인 IOC/DI, AOP, PSA(Portable Service Abstraction) 은 애플리케이션을 POJO로 개발 할 수있게 해주는 가능기술이라고 불린다.

POJO란 무엇인가?

• POJO는 Plain Old Java Object의 첫 글자를 따서 만든 약자이다.
• 마틴 파울러가 2000년에 컨퍼런스 발표를 준비하다가 만들어낸 용어이다.
• 당시 인기를 끌고 있던 EJB보다 자바의 단순한 오브젝트를 이용해 애플리케이션 비즈니스 로직을 개발하는게 낫다고 생각했다.
• 그럼에도 왜 개발자가 자바의 단순한 오브젝트를 사용하길 꺼리는지 궁금했다. 그 이유를 찾아보니 EJB와 같이 그럴싸한 이름이 없기 때문이었다. 그래서 뭔가 있어 보이도록 만든 이름이 바로 POJO였다.

POJO의 조건

1. 특정 규약에 종속되지 않는다.
   • 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다.
2. 특정 환경에 종속되지 않는다.
   • 비즈니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경정보나 웹 기술을 담고 있는 클래스나 인터페이스를 사용해서는 안 된다.
   • 비즈니스 로직을 담은 코드에 HttpServletRequest, HttpSession, 캐시와 관련된 API가 등장하거나 웹 프레임워크 클래스를 직접 이용하는 부분이 있다면 진정한 POJO라고 볼 수 없다.

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 이런 POJO에 애플리케이션의 핵심로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다