'나'가 '나'에게 설명하는 스프링부트에 대한 이야기..

 

스프링의 레이어드 아키텍쳐

처음 스프링부트를 쓸 때 Controller? Service? Repository? Dto?? Dao?? 다 뭔소린가 했는데 이 그림으로 조금이나마 정리가 된다. 그리고 또 개발에 대해 정말 무지했기 때문에 " 아니 그냥 가져다가 쓰면될걸 왜 ? 이렇게???  " 라는 생각도 했었다 ㅋㅋㅋ

 

그것은 "레이어드 아키텍처"가 뒷받침해줄 수 있어보인다.

 

Presentation 계층 사용자와 상호 작용 처리 계층 CLI, HTTP 요청, HTML 처리 등을 담당한다. HTTP 요청 처리 및 HTML 렌더링에 대해 알고 있는 웹 계층 흔히 말하는 MVC (Model / View / Controller) 도 이 계층에 속한다. Domain(Business or Service) 계층 서비스/시스템의 핵심 로직 유효성 검사 및 계산을 포함하는 Business 논리 계층 애플리케이션이 수행해야하는 도메인과 관련된 작업들을 담당한다. 입력/저장된 데이터를 기반으로 계산 Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사 어떤 Data Access 를 선택할지 결정 Data Access(Persistence) 계층 DAO 계층 Database / Message Queue / 외부 API와의 통신 등 처리 데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층

 

그럼 이 레이어드 아키텍쳐가 뭐냐,

코드를 논리적인 부분이나 역할에 따라 독립된 모듈로 나누어 구성한 패턴이다. 그 모듈이 서로의 의존도에 따라 층층히 연결되어 하나의 시스템을 구현하는 것이다. 이렇게 구조를 구성하면 확장이 쉽고, 재사용성이 높아지고, 유지보수에 용이하며 가독성이 좋아지는 등의 장점을 가진다. 그것이 바로 객체지향 프로그래밍의 지향점이기 때문에 이미 널리 쓰이는 패턴이지 않나 하는 나의 작은 생각..!

 

그러니까 간단히 정리하면?

Controller 가 데이터의 입/출구

Service 코드가 실제적인 일을 하는(?) 곳

Repository 데이터베이스 연결하는 곳  정도로 생각하면 될 것 같다.

 

계층간 이동을 할 때 데이터는 DTO에 담아서 전송하는데 내가 필요한 것만 담아서 보내고, 필요한 데이터만 담아서 올 수 있는 바구니가 아닐까 싶다.

 

 

 

 

이렇게 전체적인 구조를 파악했다면 ~ 이제 스프링 부트의 동작 원리를 알아보자

서블릿은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술이다.  이 서블릿은 서블릿 컨테이너에서 관리된다. 서블릿 컨테이너는 서블릿의 생명주기를 관리한다. 싱글톤 패턴으로 서블릿 객체를 관리하고 멀티 스레딩을 지원하는 특징을 가지고 있다. 

 

** 스프링에서는 Dispatcher Servlet이 서블릿의 역할을 수행한다.

 

 

그럼 이제 특징을 알아볼까?

스프링 부트 하면 무조건 나오는 이야기 세 가지

IoC / DI / AOP

프로그램의 객체들을 개발자가 아니라 스프링이 관리해주는데 이걸 제어가 역전되었다고 해서 제어역전 (IoC: Inversion of Control) 이라고 부른다. 객체의 제어권을 컨테이너로 넘겨서 개발자는 비즈니스 로직을 구상하는데만 집중할 수 있으니 일의 효율이 올라가지! 그럼 이 제어역전을 어떻게 하느냐? 의존성(Dependency)을 주입(Injection)해서 사용한다. 외부 컨테이너가 객체를 생성해주고 그걸 생성자를 만들어주거나, 객체를 선언하거나, setter 메소드를 사용해 주입한다. 그럼 이제 관점 지향 프로그래밍 (AOP: Aspect-Oriented Programming)을 할 수 있게 되는거지.

 

그럼 이 관점지향 프로그래밍이 뭔지 알아보자

AOP는 분명 OOP와는 다른 개념이다. AOP는 관점을 기준으로 묶어서 개발하는 방식 이라고 하는데, 어떤 기능을 구현할 때 핵심 기능과 부가 기능으로 구분해 각각을 하나의 '관점(Aspect)'으로 보고 나눈다. 여기서 핵심 기능은 비즈니스 로직이 처리하려는 목적 기능을 뜻하고 그 외의 것들을 부가 기능정도로 생각하면 될 것 같다. 

그래서 이렇게 관점별로 기능을 묶어보면 여러 비즈니스로직에서 반복되는 부가 기능이 보일 것이고 그걸 공통 로직으로 처리하면 코드는 더 깔끔해질 것이다. 

 

 

음.. 대략적인 그림은 그린 것 같네🫠

 

 

++ 그래서 스프링 / 스프링부트를 왜 쓰는건데?

: 예전에 불편했던 것을 획기적으로 편하게 해줬기 때문에 스프링 프레임워크를 사용한다. 단순 반복작업 부분이 많았던 Controller 와 Repository 쪽을 개발 관점에서 쉽고 편하게 처리해줬다고 한다. 그로인해 비즈니스 로직에만 집중할 수 있게 되었다는 이야기 ~

 

 

 

++ 아니 그럼 스프링이랑 스프링 부트랑 뭐가 달라? 했던 적이 있어 추가해보는 단락..

스프링은 말그대로 프레임 워크인데 이걸 직접 사용하려면 개발자가 직접 설정해주어야 하는 부분이 너무 복잡했다고 한다. 그래서 이 문제를 해결하기 위해 등장한 것이 스프링 부트 ..!!! 

심지어는 의존성 주입이 장점 중 하나라고 했는데 스프링에서는 각 모듈의 의존성을 직접 설정했어야한다고.. 

https://spring.io/projects/spring-boot

스프링 부트를 이용하면 단독으로 실행 가능한 상용 수준의 스프링 기반 애플리케이션을 손쉽게 만들 수 있습니다. 

 

 

 

---

 

reference

참고블로그

[Spring Boot]Controller, Service, Repository에 대하여

레이어드아키텍쳐

[Backend] 백엔드 API 패턴 - 레이어드 아키텍처 패턴(layered architecture)

스프링부트핵심가이드

스프링 부트 핵심 가이드 - YES24

DAO, DTO, Entity

[DAO] DAO, DTO, Entity Class의 차이 - Heee's Development Blog

레이어드아키텍쳐

 

계층형 아키텍처