"소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것" - Ralph Johnson -
👉 장점
👉 단점
Library
애플리케이션을 개발하는 데 사용되는 일련의 데이터 및 프로그래밍 코드
한번 정해진 Framework를 교체하는 일은 어렵지만, Library는 쉽게 교체가 가능하며 필요한 Library들을 선택적으로 사용할 수 있다.
개발자가 짜 놓은 코드 내에서 필요한 기능이 있으면 해당 라이브러리를 호출해서 사용하는 것이 바로 Library다. 즉, 애플리케이션 흐름의 주도권이 개발자에게 있다.
애플리케이션 흐름의 주도권이 개발자가 아닌 Framework에 있다.
Spring Framework의 장점
- POJO(Plan Old Java Object) 기반의 구성
- DI(Dependency Injection) 지원
- AOP(Aspect Oriented Programming, 관점지향 프로그래밍) 지원
- Java 언어를 사용함으로써 얻는 장점
Spring Framework을 학습함으로 인해서 객체 지향 설계 원칙에 잘 맞는 재사용과 확장이 가능한 애플리케이션 개발 스킬을 향상할 수 있다는 것, 그리고 보다 나은 성능과 서비스의 안전성이 필요한 복잡한 기업용 엔터프라이즈 시스템을 제대로 구축하기 위한 능력을 기를 수 있다.
Spring Framework이 도입되기 전에는 JSP나 Servlet 기술을 사용한 Model1, Model2 아키텍처를 기반으로 한 Java 웹 애플리케이션을 제작하였다.
Spring MVC 방식이 도입됨으로써 Java 웹 애플리케이션의 제작 방식이 획기적으로 변하게 되었다.
Spring MVC 설정의 복잡함과 어려움을 극복하기 위해 Spring Boot이 탄생하게 되었다.
Spring의 복잡한 설정 작업마저도 Spring이 대신 처리를 해주기 때문에 개발자는 애플리케이션의 핵심 비즈니스 로직에만 집중할 수 있게 됐다.
POJO라는 것을 IoC/DI, AOP, PSA를 통해서 달성할 수 있다는 것을 의미
POJO 프로그래밍으로 작성한 코드라고 불리기 위해서는 크게 두 가지 정도의 기본적인 규칙
- Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.
- 특정 환경에 종속적이지 않아야 한다.
POJO 프로그래밍이 필요한 이유
- 특정 환경이나 기술에 종속적이지 않으면 재사용 가능하고, 확장 가능한 유연한 코드를 작성할 수 있다.
- 저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거함으로써 코드가 깔끔해진다.
- 코드가 깔끔해지기 때문에 디버깅하기도 상대적으로 쉽다.
- 특정 기술이나 환경에 종속적이지 않기 때문에 테스트 역시 단순해진다.
- 객체지향적인 설계를 제한 없이 적용할 수 있다.(가장 중요한 이유)
Spring은 POJO 프로그래밍을 지향하는 Framework
Library는 애플리케이션 흐름의 주도권이 개발자에게 있고, Framework은 애플리케이션 흐름의 주도권이 Framework에 있다. 여기서 말하는 애플리케이션 흐름의 주도권이 뒤바뀐 것을 바로 IoC(Inversion of Control)라고 한다.
Java 콘솔 애플리케이션의 경우 main() 메서드가 종료되면 애플리케이션의 실행이 종료된다. 하지만 웹에서 동작하는 애플리케이션의 경우 클라이언트가 외부에서 접속해서 사용하는 서비스이기 때문에 main() 메서드가 종료되지 않아야 한다. 그런데 서블릿 컨테이너에는 서블릿 사양(Specification)에 맞게 작성된 서블릿 클래스만 존재하지 별도의 main() 메서드가 존재하지 않는다. main() 메서드처럼 애플리케이션이 시작되는 지점을 엔트리 포인트(Entry point)라고도 부른다. main() 메서드가 없는데 어떻게 애플리케이션이 실행되는 걸까? 서블릿 컨테이너의 경우, 클라이언트의 요청이 들어올 때마다 서블릿 컨테이너 내의 컨테이너 로직(service() 메서드)이 서블릿을 직접 실행시켜 주기 때문에 main() 메서드가 필요 없다. 이 경우에는 서블릿 컨테이너가 서블릿을 제어하고 있기 때문에 애플리케이션의 주도권은 서블릿 컨테이너에 있다. 바로 서블릿과 웹 애플리케이션 간에 IoC(제어의 역전)의 개념이 적용되어 있는 것이다.
IoC(제어의 역전)는 서버 컨테이너 기술, 디자인 패턴, 객체 지향 설계 등에 적용하게 되는 일반적인 개념인데 반해 DI(Dependency Injection)는 IoC 개념을 조금 구체화시킨 것이라고 볼 수 있다.
A 클래스의 프로그래밍 로직 완성을 위해 B 클래스에게 도움을 요청한다. ‘ 즉, ‘B 클래스에게 의지(의존)한다.
클래스의 생성자로 객체를 전달받는 코드가 있다면 ‘아, 객체를 외부에서 주입받고 있구나. 의존성 주입이 이루어지고 있구나’
애플리케이션 코드 내부에서 직접적으로 new 키워드를 사용할 경우 객체지향 설계의 관점에서 중요한 문제가 발생할 수 있다. new 키워드를 사용해서 객체를 생성하게 되면 참조할 클래스가 바뀌게 될 경우, 이 클래스를 사용하는 모든 클래스들을 수정할 수밖에 없다. 이처럼 new 키워드를 사용해서 의존 객체를 생성할 때, 클래스들 간에 강하게 결합(Tight Coupling)되어 있다고 한다. 결론적으로 의존성 주입을 하더라도 의존성 주입의 혜택을 보기 위해서는 클래스들 간의 강한 결합은 피하는 것이 좋다. 느슨한 결합(Loose Coupling)이 필요하다.
Java에서 클래스들 간의 관계를 느슨하게 만드는 대표적인 방법은 바로 인터페이스(Interface)를 사용하는 것
✔️ BUT 클래스들 간의 관계를 느슨하게 만들기 위해서는 new 키워드를 사용하지 않아야 되는데, CafeClient 클래스의 (1)을 보면 MenuServiceStub의 객체와 MenuController 객체를 생성하기 위해 여전히 new를 사용하고 있다.이 new 키워드는 어떻게 하면 제거하고 의존 관계를 느슨하게 만들 수 있을까? 바로 Spring이 대신해 준다.
Config 클래스에 정의해 둔 MenuController 객체를 Spring의 도움을 받아서 CafeClient클래스에게 제공을 하고 있는 것
애플리케이션에 필요한 기능 중에서 공통적으로 적용되는 공통 기능에 대한 관심과 관련이 있다. AOP라는 것은 애플리케이션의 핵심 업무 로직에서 로깅이나 보안, 트랜잭션 같은 공통 기능 로직들을 분리하는 것
애플리케이션을 개발하다 보면 애플리케이션 전반에 걸쳐 공통적으로 사용되는 기능들이 있기 마련인데, 이러한 공통 기능들에 대한 관심사를 바로 공통 관심 사항(Cross-cutting concern)이라고 한다. 그리고 우리가 흔히들 말하는 비즈니스 로직 즉, 애플리케이션의 주목적을 달성하기 위한 핵심 로직에 대한 관심사를 핵심 관심 사항(Core concern)이라고 한다.
- 코드의 간결성 유지
- 객체 지향 설계 원칙에 맞는 코드 구현
- 코드의 재사용
- 객체지향 프로그래밍 세계에서 어떤 클래스의 본질적인 특성만을 추출해서 일반화하는 것을 추상화(Abstraction)라고 한다.
- 클라이언트가 추상화된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것이 바로 일관된 서비스 추상화(PSA)의 기본 개념이다.
- 애플리케이션에서 특정 서비스를 이용할 때, 서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 하는 것을 PSA(일관된 서비스 추상화)라고 한다.
- PSA가 필요한 주된 이유는 어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지함으로써 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위함이다.
- 아키텍처(Architecture)는 건축 분야에서 유래된 용어로써 요구 사항을 만족하는 건축물을 짓는 데 있어 청사진 같은 역할을 한다.
- 소프트웨어의 구성을 큰 그림으로 표현한 것이 소프트웨어 아키텍처이다.
- 애플리케이션은 소프트웨어 종류의 하나로서 좁게는 데스크톱이나 스마트폰에서 사용하는 응용 프로그램을 말하며, 넓게는 클라이언트의 요청을 처리하는 서버 애플리케이션을 의미한다.
- 중점적으로 알아야 할 아키텍처는 웹 상에서 동작하는 웹 애플리케이션을 위한 아키텍처이다.
- 애플리케이션의 아키텍처 중에서 우리가 중점적으로 알아야 할 아키텍처는 계층형 애플리케이션 아키텍처이다.
- REST API 기반 웹 애플리케이션의 계층은 크게 API 계층(API Layer), 비즈니스 계층(Business Layer), 데이터 액세스 계층(Data Access Layer)으로 구분된다.
- API 계층은 클라이언트의 요청을 받아들이는 계층이다.
- 비즈니스 계층은 API 계층에서 전달받은 요청을 업무 도메인의 요구 사항에 맞게 비즈니스적으로 처리하는 계층이다.
- 데이터 액세스 계층은 비즈니스 계층에서 처리된 데이터를 데이터베이스 등의 데이터 저장소에 저장하기 위한 계층이다.
모듈(Module)이란?
Java에서는 일반적으로, 지원되는 여러 가지 기능들을 목적에 맞게 그룹화하여 묶어 놓은 것을 모듈이라고 부른다.
이러한 모듈들은 Java의 패키지 단위로 묶여 있으며, 이 패키지 안에는 관련 기능을 제공하기 위한 클래스들이 포함되어 있다.
일반적으로 모듈은 재사용 가능하도록 라이브러리 형태로 제공되는 경우가 많다.
Spring Boot은 Spring 설정의 복잡함이라는 문제점을 해결하기 위해 생겨난 Spring Project 중 하나이다.
Spring Boot을 사용해야 하는 이유
- Spring Boot은 XML 기반의 복잡한 설계 방식을 지양한다.
- Spring Boot의 starter 모듈 구성 기능을 통해 의존 라이브러리를 자동으로 구성해 준다.
- 애플리케이션 설정의 자동 구성
- Spring Boot은 프로덕션급 애플리케이션의 빌드를 손쉽게 할 수 있다.
- Spring Boot은 내장된 WAS를 사용가능하기 때문에 배포가 용이하다.
Spring Boot의 핵심 콘셉트