SpringBoot Part 1-1

 

SpringBoot Part 1-1

1. Maven이란

 

Build Tool

- Gradle

- Maven

 

Build란 무엇일까?

 

- 필요한 라이브러리를 다운로드하고 classpath에 추가한다.

- 소스 코드 컴파일

- 테스트 실행 (코드에 문제 없는 지 확인)

- 컴파일 된 코드를 packaging 한다. -> jar, war, zip..

- packing 된 파일을 주로 artifacts라고 부르고 서버나 레포지코리에 배포한다.

 

Maven

 

- 빌드 도구

- XML 기반으로 설정 모델을 제공하고 pom.xml파일로 작성한다.

* POM(Project Object Model)

 

Maven의 사용 이유

 

- archetypes라는 프로젝트 템플릿을 제공해서 프로젝트 설정의 반복을 줄여준다.

-  외부 라이브러리인 dependency를 관리해 준다.

- 플러그인과 외부 라이브러리를 분리하여 관리한다.

-  dependency를 다운로드하는 repository가 로컬이 될 수도 있고 Maven Central과 같은 공개된 Repository가 될 수도 있다.

 

Maven Coordinates

 

Maven 프로젝트에서 아티팩트를 고유하게 식별하는 정보

 

- Group Id: 프로젝트를 생성한 조직 또는 그룹을 식별하는 식별자. 주로 회사명, 단체명을 작성

ex) org.springframework, org.prgms

 

- Artifact Id: Maven 프로젝트의 아티팩트를 식별하는 식별자. 주로 프로젝트 명 사용

ex) my-project, customer-service

 

- Version: 아티팩트의 특정 버전을 식별하는 식별자. 프로젝트의 버전 작성. 아티팩트의 변경 사항과 호환성을 관리하는 데 사용

ex) 0.0.1-RELEASE(릴리즈 버전), 1.0-SNAPSHOT

 

✅정리

Maven Coordinates는 Maven의 의존성 관리 시스템에서 중요한 역할을 한다.

프로젝트의 pom.xml 파일에 이러한 좌표를 명시하여 필요한 의존성을 선언하고, Maven은 해당 의존성을 찾아서 다운로드하여 프로젝트에 추가한다. 이를 통해 프로젝트의 의존성 관리와 버전 관리를 편리하게 할 수 있다.

 

Maven Multiple Module

 

단일 Maven 프로젝트에서 여러 개의 관련된 모듈을 함께 관리하는 방식

=> 하나의 프로젝트에서 여러 프로젝트를 관리할 수 있다.

 

부모(Parent) 프로젝트와 여러 개의 자식(Child) 모듈로 구성된다.

각 모듈은 독립적으로 컴파일, 패키징 및 테스트될 수 있으며, 공통된 부모 프로젝트의 설정을 상속받을 수 있다.

 

예시

<modules>
 <module>service-a</module>
 <module>service-b</module>
</modules>

 

Build Lifecycle

 

Maven 프로젝트의 빌드 과정을 단계별로 정의하고 실행하는 일련의 작업들의 집합

 

프로젝트를 빌드, 패키징, 테스트, 배포 등의 작업을 자동화하여 개발자가 일관된 방식으로 프로젝트를 빌드할 수 있도록 도와준다.

 

Intellij

📌 라이프 사이클 종류

👆 Clean Lifecycle

빌드 이전에 프로젝트를 정리하는 작업을 수행

clean 단계를 실행하면 이전 빌드에서 생성된 결과물(컴파일된 클래스, 패키징 된 파일 등)을 삭제한다.

👆 Default Lifecycle

Maven 프로젝트의 주요 빌드 과정을 처리

compile, test, package, install, deploy 등의 단계로 구성되어 있다.

각 단계는 이전 단계의 결과물을 기반으로 작업을 수행한다.

👆 Site Lifecycle

프로젝트의 문서화와 웹 사이트 생성을 위한 작업을 수행

site 단계에서는 프로젝트 문서를 생성하고, deploy 단계에서는 문서를 웹 서버에 배포한다.

이를 통해 프로젝트 문서, API 문서, 보고서 등을 생성하고 공유할 수 있다.

pom.xml 파일에서 선언된 명령어를 실행하여 빌드 과정을 자동화한다.

Maven은 빌드 라이프사이클에 정의된 각 단계에서 필요한 작업을 실행하고, 의존성 관리와 설정 정보를 통해 빌드를 제어한다. 이를 통해 개발자는 일관된 방식으로 프로젝트를 빌드하고, 필요한 작업을 자동으로 수행할 수 있다.

 

📌 각 라이프 사이클 설명

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

 

Transitive Dependencies

 

추이적 의존성, 의존성의 의존성

직접적으로 선언한 의존성이 다른 라이브러리 또는 모듈에 의존하는 경우, 해당 라이브러리 또는 모듈도 프로젝트의 의존성으로 간주된다.

 

예를 들어, 프로젝트 A가 라이브러리 B에 직접적으로 의존하고, 라이브러리 B가 다시 라이브러리 C에 의존하는 경우, 프로젝트 A는 B와 C 모두에 대한 추이적 의존성을 가지게 된다.

Maven은 이러한 추이적 의존성을 자동으로 해결하여 필요한 모든 라이브러리를 다운로드하고 프로젝트에 추가한다.

또한 동일한 groupId, artifactId에 대해서는 가장 최신의 version정보를 사용한다.

✅정리

- Transitive Dependencies를 사용하면 개발자는 직접적으로 필요한 라이브러리만 선언하고, Maven은 해당 라이브러리의 의존성을 자동으로 처리한다.

- 의존성 관리를 편리하게 해 주고, 라이브러리 간의 의존성 충돌을 방지할 수 있도록 도와준다. (하지만 때론 충돌이 발생하기도 한다.)

- Maven은 의존성 트리를 통해 추이적 의존성을 해결하므로 개발자는 필요한 라이브러리만 명시적으로 선언하면 된다.

 

의존 범위 (Dependency Scope)

 

프로젝트의 의존성이 컴파일, 테스트, 런타임 또는 배포 단계에서 어떻게 사용되는지를 정의하는 개념

dependency를 작성할 때 의존성 범위를 지정할 수 있다.

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>${junit-version}</version>
    <scope>test</scope>
</dependency>

 

👆 Compile 

기본적으로 모든 의존성은 컴파일 범위로 설정된다. => <scope>를 지정하지 않은 경우, 기본값으로 설정

컴파일 의존성은 프로젝트의 컴파일, 테스트, 실행(런타임)에 라이브러리가 필요할 때 사용한다.

 

👆 Provided

일반적으로 JDK 또는 컨테이너가 해당 라이브러리를 제공할 때 설정한다. 

즉, 웹 애플리케이션의 경우 JSP와 Servlet API 등은 provided 의존성으로 설정한다.

컴파일, 테스트 단계에서 사용되고 런타임 클래스 경로에는 추가되지 않는다.

 

👆 Runtime

컴파일 시에는 사용되지 않고 런타임과 테스트에 사용된다.

ex) JDBC 드라이버

 

👆 Test

애플리케이션 실행에는 사용되지 않고 테스트 컴파일 및 실행 단계에서만 사용할 수 있다.

일반적으로 이 범위는 JUnit 및 Mockito와 같은 테스트 라이브러리에 사용된다.

 

👆 System

provided 의존성과 비슷하지만, 사용자가 jar 파일의 위치를 지정한다는 점이 다르다.

<systemPath>.. </systemPath> 엘리먼트를 이용하여 jar 파일의 위치를 지정해야 한다. 

+) 사용자마다 개발 환경이 다를 수 있으므로 프로퍼티를 이용하여 jar 파일의 위치를 지정하는 것이 좋다.

---

2. Gradle이란

 

Gradle

 

- Build Tool (빌드 도구)

- Groovy, Kotlin기반으로 빌드 스크립트를 작성

 

Maven vs Gradle

 

👆 Maven

Maven은 Java 프로젝트 관리 도구로, 빌드 도구이면서 라이프사이클 관리를 목적으로 한다.

Apache Ant의 대안으로 개발되었으며, Apache 라이선스로 배포되는 오픈 소스 소프트웨어이다.

👆 Gradle

Gradle은 Maven을 대체할 수 있는 프로젝트 구성 관리 및 범용 빌드 도구이다.

Ant Builder와 Groovy 스크립트를 기반으로 구축되어 기존 Ant의 역할과 배포 스크립트의 기능을 모두 사용할 수 있다.

Gradle은 스프링 부트와 안드로이드 프로젝트에서 널리 사용된다.

---

3. Spring Framework

 

Spring은 여러 프로젝트로 구성되어 있는 자바 기반의 프로그래밍에 있어서 방대한 기능을 제공하는 Framework라고 볼 수 있다.

 

 

프로젝트 목록

https://spring.io/projects

https://spring.io/projects

 

Spring Boot의 주요 기능

 

- SpringApplication을 통한 손쉬운 실행

- Auto Configuration - 자동으로 빈(bean)을 생성하고 구성

- 쉬운 외부 환경 설정 - Properties, YAML, Command line 설정 등

- 프로파일을 통한 실행환경 관리 (ex. application.yml, application.properties)

- Packaging Executable Jar (. jar파일로 패키징)

- Developer Tools

---

4. Spring Framework의 핵심 개념

 

Domain Driven Design

 

💡 Domain

 

사용자가 애플리케이션을 사용하는 대상 영역

 

ex) 주문 관리 애플리케이션의 도메인은 주문 관리

 

💡 Entity

 

- 다른 엔터티와 구별할 수 있는 식별자(ID)를 가진다.

- 시간의 흐름에 따라 지속적으로 변경이 되는 객체

 

ex) 주문 관리 시스템에서 매 주문(엔티) 개별성을 가진다. 각 주문은 독립적이다.

주문의 상태로는 주문 확인, 배송 준비, 배송 중, 배송 완료가 있다. -> 상태 변경 가능

 

💡 Value Object

 

- 고유한 식별자(ID)를 가지지 않으며, 값에 의해 식별된다.

- 불변하며, 상태가 변경되지 않는다.

 

ex) 주문 관리 시스템에서 주소

주소는 도시, 거리, 우편번호 등의 속성을 가지고 있으며 두 개의 주소 객체가 동일한 도시, 거리, 우편번호를 가지면 같은 주소로 간주된다.

 

새로 알게 된 문법 정리

 

💡Stream - reduce()

 

- 정의된 연산이 아닌 프로그래머가 직접 구현한 연산을 적용한다.

 

T reduce(T identity, BinaryOperator<T> accumulator);

- identity: 초기 값으로 사용할 값. 스트림이 비어있을 경우 해당 값을 리턴한다.

- accumulator: 두 개의 인수를 받아서 연산을 수행하는 BinaryOperator. 스트림의 요소를 차례로 처리하면서 적용된다.

* BinaryOperator: Java의 함수형 인터페이스 중 하나로, 두 개의 동일한 타입의 인자를 받아 동일한 타입의 결과를 반환하는 연산을 수행하는 함수.

 

ex) 배열의 모든 요소의 합을 구하기

arr.stream().reduce(0L, Long::sum);
arr.stream().reduce(0L, (a, b) -> a + b);

윗 줄: BinaryOperator <Long> 타입의 메서드 참조 (Long::sum)

* 메서드 참조는 Java에서 함수형 인터페이스를 사용하는 람다식을 간결하게 표현하기 위한 기능

아래 줄: BinaryOperator <Long> 형태의 람다식 사용 ((a, b) -> a + b)

 

 

💡 record 타입

 

Java 14부터 도입된 데이터를 저장하고 관리하기 위한 간단하고 불변(immutable)한 클래스를 생성하는 데 사용되는 특별한 종류의 클래스

public record OrderItem(UUID productId,
                        long productPrice,
                        long quantity) {
}

 

 

👆 특징
필드 선언: record 클래스는 필드를 선언할 수 있으며, 이러한 필드는 final 및 private으로 암묵적으로 선언된다.
생성자: record 클래스는 기본 생성자를 자동으로 생성하며, 필드 값을 초기화하기 위한 매개변수를 가질 수 있다.
필드 접근 메서드: record 클래스는 자동으로 필드에 대한 접근자(getter) 메서드를 생성합니다. 이 메서드는 필드의 값을 반환한다.
equals(), hashCode(), toString(): record 클래스는 자동으로 equals(), hashCode(), toString() 메서드를 생성한다. 이들 메서드는 필드 값을 기반으로 객체의 동등성 비교, 해시 코드 생성, 문자열 표현을 담당한다.

 

record 타입의 사용은 간단하고 명료한 데이터 객체를 생성하기 위해 편리하다.

주로 DTO(Data Transfer Object), VO(Value Object)등 데이터 저장을 위한 객체로 활용될 수 있다.

---

5. 의존성 관리

 

결합도란?

 

하나의 객체가 변경이 일어날 때 관계를 맺고 있는 다른 객체에게 변화를 요구하는 정도

 

두 객체 사이의 의존성이 바람직할 때: 약한 결합도, 느슨한 결합도

두 객체 사이의 의존성이 바람직하지 못할 때: 강한 결합도, 단단한 결합도

 

의존성이란?

 

어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때, 두 객체 사이의 의존성이 존재하게 된다.

의존성은 구현 시점(컴파일 타임)과 실행 시점(런 타임)에 다른 의미를 가진다.

 

- 컴파일 타임 의존성: 코드를 작성하는 시점에서 발생, 클래스 사이의 의존성

- 런타임 의존성: 애플리케이션이 실행되는 시점에서 발생, 객체 사이의 의존성

 

📢 컴파일 타임 의존성 => 강력한 결합도

 

public class Order {
    private FixedAmountVoucher fixedAmountVoucher;
	
    public Order(long discountAmount) {
        this.fixedAmountVoucher = new FixedAmountVoucher(discountAmount);
    }  
}

Order와 FixedAmountVoucher(고정된 금액을 할인)는 클래스 타입에서 단단한 결합도 존재

 

FixedAmountVoucher에 변경이 일어나면 Order에도 큰 변화가 일어난다.

=> 다른 Voucher의 방법을 적용하기 위해서는 많은 변경이 필요하다.

 

📢  런타임 의존성 => 느슨한 결합도

 

public interface Voucher {
    long discount(long beforeDiscount);
}

public class FixedAmountVoucher implements Voucher{
    private final long amount;

    public FixedAmountVoucher(long amount) {
        this.amount = amount;
    }

    public long discount(long beforeDiscount) {
        return beforeDiscount - amount;
    }
}

public class Order {
    private Voucher voucher;

    public Order(Voucher voucher) {
        this.voucher = voucher;
    }
}

public class Main {
    public static void main(String[] args) {
        FixedAmountVoucher fixedAmountVoucher = new FixedAmountVoucher(10L);
        Order order = new Order(fixedAmountVoucher);
    }
}

Order에게 런타임에 특정한 Voucher객체를 생성해서 전달해 주는 방식

 

- Order는 interface와 의존관계를 가지고 실제 구현체와는 가지지 않는다.

- FixedAmountVoucher와 PercentAmountVoucher가 Voucher 인터페이스를 implements 하고 있기 때문에 Voucher방식이 바뀌어도 Order클래스에서의 변경은 없다.

 

 

Reference

Java 14 Record Keyword