📖 그 주의 주말에 업데이트가 완료됩니다. [학습에 따라 더 수정할 예정입니다!]
구조를 알아보기 앞서 Batch Processing 이 무엇이고, Spring-Batch 는 무엇인지, 언제 사용하는지 등에 관하여 먼저 알아보자.
Batch
의 사전적 의미는 '집단, 무리, 함께 묶다' 이다.
이와 같이, 배치(Batch) 프로세싱이란 일괄처리
라는 의미의 work이며 일련의 작업을 정해진 로직으로 수행하는 작업이다.
어떤 요청이 있을 때마다 실시간으로 통신하는 것이 아닌 한꺼번에 일괄적으로 대량 건을 처리 하는 것으로,
'일괄'의 의미에 맞게 보통 정해진 특정한 시간(ex. 주 1회)에 실행하는 것이다.
이와 관련하여 Spring-Batch는 스프링에서 제공해주는 대용량 일괄처리의 편의를 위한 배치 프레임워크이다.
관련하여 작성한 포스팅
더 자세한 Batch에 대한 설명은 포스팅으로 작성하였습니다.
도커(Docker)에 관해서는 이전에 학습하고 정리했던 포스팅이 있다.
이번에는 docker-compose 에 대해서 정리하고자 한다.
'compose' 의 사전적 의미는 [구성하다] 이다.
이에 맞게 docker-compose 는 docker를 사용하는 방법중 하나로, 여러 컨테이너 도커 어플리케이션을 구성,정의하고 실행하는 도구이다.
docker의 많은 설정값들을 설정 파일 하나(docker-compose.yml
)에 저장해서, 간단한 up/down 명령어로 설정된 모든 컨테이너를 실행 시킬 수 있다.
도커 회고해보기
- 컨테이너란?
도커 이미지를 독립된 공간에서 실행할 수 있게 해주는 기술- 도커 이미지란?
코드, 런타임, 시스템 라이브러리 및 설정 등 프로그램을 실행하는데 필요한 모든 것을 포함하는 패키지
(컨테이너를 실행하기 위한 모든 정보)
빌더 패턴(Builder pattern)이란?
'복합 객체의 생성 과정과 표현 방법을 분리해 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴이다.'
위키백과에 따르면 빌더 패턴을 다음과 같이 정의하고 있다. 이게 무슨 말일까?
간략하게 설명하자면 생성자 오버로딩
이라고 볼 수 있다.
객체를 생성할 때 보통 생성자를 통해 생성하게 되는데, 이때 생성자를 통해 객체를 생성하는데 몇 가지 단점이 있어 객체를 생성하는 별도 builder 를 두는 방법이 있는 것이다.
빌더 패턴을 사용하게 되면, 생성자의 실수를 줄이고, 여러개의 생성자를 생성하지 않도록 도와 자바의 다형성과, 개발자의 편의성을 보장할 수 있다.
Builder 를 구현하는 방법으로는 static inner 클래스로 지정하고 그 안에서 멤버 필드별로 값을 설정하고 .build() 를 통해서 객체를 반환하는 방법이 있다.
하지만 이렇게 작성하게 되면 시간적인 소요 코드 길이의 복잡함.. 등이 생길 수 있기 때문에,
롬복에서는 편리하게 @Builder 어노테이션을 제공해준다.
@Builder
public class Student {
private String name;
private int age;
}
Student student = Student.builder()
.name("kim")
.age(20)
.build();
생성자를 통해 객체를 생성할 때의 단점
- 생성자 파라미터가 많을 경우 가독성이 좋지 않다.
- 생성자 생성시 인자를 잘 못 작성하게 되더라도 (타입이 일치한다면) 생성자를 직접 열어보지 않는 이상 버그발생 시 무엇이 문제인지 알 수 없다.
→ 하지만 이를 빌더 패턴으로 구현하면 각 값들은 빌더의 각 값들의 이름 함수로 셋팅이 되지 각각 무슨 값을 의미하는지 파악하기 쉽다.
[참조] JobBuilderFactory, StepBuilderFactory
Job 인터페이스 구현체는 다양하고 설정 방법도 다른데, builder로 이를 추상화한다.
return jobBuilderFactory.get("Job1") .start(Step1()) .next(Step2()) .build();
퍼사드 패턴(Facade Pattern)이란?
인터페이스를 단순화시키기 위한 용도로 간단한 통합 인터페이스를 제공해주는 역할이라고 볼 수 있다.
이러한 패턴을 controller
- service
- repository
Layers 에서도 적용시켜볼 수 있다.
Service Layer 관련 의존성 낮추기
service layer 와 관련하여 의존성을 낮추는데 facade 를 통해 해결할 수 있다.
Service 레이어에서 Repository를 너무 많이 의존하지 않도록, facade 클래스가 여러개의 Service 레이어를 한데 모아서 처리를 해줌으로써 의존성을 낮추고 응집도는 올리는 것이다.
controller 에서도 여러 service를 호출하기보다 하나의 facade만을 선언함으로써 보다 깔끔하게 유지할 수 있다.
모르는게 쏟아진다..!!!🌋 Batch, MSA, docker-compose, Jooq, cache.......
모르는게 많은데 시간 안에 적절하게 다 공부하지 못해서 큰일났다.🥵
새로운 아키텍처에 감을 못잡느라 힘들었던 것도 있고, Batch 관련해서 토이 프로젝트를 실행하며 익혀보려고했지만 mysql 설정 문제에서 자꾸 오류가 발생해서 삽질을 며칠을 했다(하고있다)...^^ 다음주에는 꼭 밀린 부분들까지 학습을 완료하자!!!
[참조]
https://pamyferret.tistory.com/67
https://catch-me-java.tistory.com/40
https://mangkyu.tistory.com/163 - builder
https://velog.io/@lsj8367/Facade-Pattern-적용기
https://github.com/lsj8367/DesignPattern/blob/master/src/structural/facade/facade.md - facade