[Spring Framework] SpringBoot를 이용한 정형화된 백엔드 시스템 개발

(해당 블로그의 정리 내용은 : 우아한형제들의 개발 팀장으로 계시는 김영한님의 스프링 부트를 이용한 백엔드 시스템 개발을 기반으로

제작하였습니다! )

 

inflearn 김영한 강사님의 SpringBoot 강의 링크 : 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%9E%85%EB%AC%B8-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8/dashboard

---

오늘은 Back-End시스템의 정형화되어진 개발 모델과 스프링 프레임워크에서 사용되는 DI 컨테이너,  그리고  Bean에 대해서 알아보고자 합니다!

 

 

스프링 프레임워크를 사용하는 것 뿐만 아니라, 다른 프레임 워크를 사용하여 서비스를 개발할 때에도 사용자와 UI/UX를 통해 직접

상호작용하는 Front-End 시스템에 비해 상대적으로 가변성이 적은 Back-End시스템은 지금까지 여러 시스템이 개발되어져 오면서 

 

일종의 정형화된 모델이 만들어 지기 시작했습니다! 정형화된 모델의 구성요소는 크게 네 가지로 구분합니다. 

 

• Domain : 서비스를 이용하는 Client의 정보(회원정보, 주문정보 등)가 담길 Object
• Repository : Domain이 저장될 데이터베이스의 로직이 구현되어있는 요소
• Service : 실제 비즈니스 로직(제품 주문하기, 회원 새로 등록하기, 정보 조회하기 등)이 구현되어있는 요소
• Controller : API를 설계하여 사용자의 요청에 따라 호출되는 기능(비즈니스 로직)을 구분하여 작동하는 요소

 

 

위와 같은 네 개의 정형화된 요소들이 서로 상호작용을 하며 클라이언트(사용자)의 요청을 처리하고 특정 목적에 맞게 구현된 서비스를

제공하는 백엔드 시스템이 개발이 된다! 라고 생각하시면 될 것 같습니다. 

 

그래서 위의 요소들을 설명한 이유는 무엇일까?? 의 답은 바로 의존관계 때문입니다. 

위의 네 가지들은 의존하는 관계를 가지고 있는데 이를 표현한 것은

 

 

Spring DI Container example

이런 그림을 나타낼 수 있습니다. (빨간색 화살표로 가르키는 방향이 의존성을 나타냅니다. ex. Repository는 Domain에 의존하고 있고, Domain은 의존하고 있는 요소가 없습니다)

 

이러한 구성요소들을 제공하려는 서비스에 맞게 실제로 구현 한 구현체가(Spring에서는 위의 요소들을 단순히 interface로 선언을 하고 실제 구현체를 만들어 Bean으로 등록합니다.) 스프링 프레임워크에서 사용되는 Bean 이라는 요소입니다. 

 

위의 그림을 보고있자니 "의존성을 가지고 있으면 따로 분리하지 말고 그냥 한번에 다 구면하면 안돼?" 라는 의문점이 들 수 있습니다.

의존관계를 가지고 있음에도 분리를 해서 구현을 하는 이유는 바로 개발의 유연성(객체지향의 다형성을 이용하는 원리) 때문인데요! 

예를들어, 서비스를 개발하면서 시작 단계에 모든것이 정해진 상태로 개발이 진행되는 경우는 흔하지가 않습니다.

(데이터베이스는 뭐로 쓸건지,  비즈니스 로직에 대한 추가와 수정 등이 확실히 정해졌는지 등의)

그래서 이런 세부적인 요소가 정해지지 않더라도  큰 규모의 서비스 개발을 진행할 수 있도록 하기 위해서 이렇게 분리를 하여 개발을 하고,

최종적인 환경설정을 하는 클래스를 따로 두어 해당 필드 내에서만 정책이나 DB등의 변경을 하도록(코드변경을 최소화 하도록) 구조를 만들어 개발을 하고 있습니다. 

 

오늘은 백엔드 시스템의 기본적인 구조와 스프링 Bean에 대해서 간단히 알아보았는데요!

다음번엔 Singletom pattern에 대해서 다루어보는 시간을 갖도록 하겠습니다!

 

(혹시라도 틀린 부분이나 애매한 부분이 있다면 댓글로 남겨주세요!)