[Spring] Spring Boot 프로젝트 고군분투 1주차

최근 Spring Boot 프로젝트 스터디에 들어갔는데.. 현직자들이 많은 것같았다.

따라가기가 사실 너어어어무 힘들지만

일단 다른 사람들 코드를 보면서, 그리고 멘토님 코드를 보면서 계속 공부해야겠다

 

스터디에서 추천해준 책인 '토비의 스프링 3.1'도 정말정말 큰 도움이 되고있다.

정말 말 그대로 스프링의 기술적인 부분보다도 스프링 자체를 이해하고싶다면 이 책은 정말 ㄹㅇ 바이블..

주변에 벡앤드 공부하는 친구가 있다면 추천해주고 싶지만 그런 친구가 없기때문에... (훌쩍)

이 기쁨을 함께할 수 없어서 살짝 아쉽다..

 

요 근래 느낀 바, 배운 점들에 대해 적어보려한다.

 

< Commit >

Commit period

Commit을 기능 단위로 해야한다고 말은 들었지만, 와닿지 않았다.

근데 정말 생각보다 더 자잘하게 Commit을 해야한다는 것을 느꼈다.

딱 Commit 로그를 봤을 때 개발 흐름을 알 수 있을 정도로

 

Commit Convention

그리고 아래 링크와 같이

https://geonlee.tistory.com/190

[git] 🤔 git 커밋 어떻게 써야하는가?

www.conventionalcommits.org/en/v1.0.0/

Conventional Commits

커밋할 때,

<type>[optional scope]: <description>

보통 이런 방식을 사용한다는 걸 처음 알았다.

나는 Add methodname() Create methodname() 이런 식으로 했는데.. 앞으로 고쳐야겠다.

 

이후 커밋 메세지는 위와같은 방식을 사용했더니 훨씬 깔끔해졌다.

 

 < Spring >

Spring 

책을 읽으면서 느낀거지만 Spring은 철저히 객체지향원칙을 따르는 프레임워크같다. Spring의 모든 전략과 도구들은 모두 OOP를 달성하기 위해 만들어진 것들이라고 해도 과언이 아닐 정도. 살짝 코넬 노트 방식(OOP)은 우등생(Spring)이 자주쓰는 필기법이라서 너도나도 이 방식으로 공부(Spring 프로젝트 진행)하는 느낌.. 억지 끼워 맞추기.. 허허

 

템플릿 메소드 패턴

변하지 않은 기능들은 슈퍼클래스에, 자주 변경되거나 확장할 기능들은 서브클래스에 만드는 방식을 말한다. 슈퍼클래스에서는 훅 메소드를 만들어 서브클래스에서 선택적으로 오버라이드할 수 있도록 한다. 상속을 통해 확장성을 획득할 수 있는 패턴이다.

 

팩토리 메소드 패턴

서브클래스에서 오브젝트 생성 방법과 클래스 결정 메소드를 정의하는 방식을 말한다. 이를 통해 오브젝트 생성 책임을 슈퍼클래스에서 서브클래스로 이동시킬 수 있다!! (+ 장점을 추가하자)

 

Application Architecture

3계층 아키텍쳐 (토비 784p ~)

일단 계층을 3개로 분할하는 이유는 관심, 책임을 분리하여 보다 유연하고 안전한 작업을 할 수 있게끔 하기 위함이다. 때문에 다른 계층과는 낮은 결합도를 유지해야한다. 계층 사이의 호출은 최대한 인터페이스를 통해 이루어지게 하여 서로간의 의존성을 낮추어 확장성을 확보할 수 있게 된다. 또한 각 계층 안에서는 높은 응집도를 가지고 있어야한다. 예를 들어 DB를 바꾸기 위해서 100개의 메소드 안에 있는 코드를 일일이 수정할 필요 없이, 하나의 코드만 수정해도 100개의 메소드가 정상적으로 변경사항을 수용할 수 있게 해야한다. 낮은 결합도 그리고 높은 응집도 둘 다 추상화를 통해서 획득가능하다. 3계층 아키텍처도 마찬가지이다. 큰 프로젝트를 추상화하기 위한 하나의 수단이라고 생각한다.

 

3계층 아키텍처에는 데이터 엑세스 계층, 서비스 계층, 그리고 프레젠테이션 계층으로 이루어져있다. 데이터 엑세스는 말 그대로 DB의 데이터에 접근하기 위한 인터페이스 역할을 하는 계층을 말한다. 흔히 DAO(Data Access Object) 계층이라고도 한다. 나는 Repository라는 말을 선호한다. 서비스 계층은 핵심적인 비지니스 로직을 포함하는 계층이다. DAO를 호출하여 데이터를 얻고 이를 활용하는 역할을 한다. 사실 프레젠테이션 계층은 정확하게 이해하진 못했다. 웹, UI 그리고 MVC 계층이라고도 불리는데 UI 부터 (자바의 경우) 서블릿 엔진까지 넓은 범위를 포괄하는 계층으로 일단 이해하고 넘어가려 한다.

 

오브젝트 중심 아키텍쳐

도메인 모델을 반영하는 오브젝트 구조를 만들고 이를 각 계층 사이에서 정보를 전송하는데 사용한다는 특징이 있다. 이 아키텍쳐가 구현이 가능한 가장 큰 특징은 자바의 레퍼런스 기능때문! 도메인 모델을 반영하는 두 개의 오브젝트가 존재한다고 했을 때, 레퍼런스 변수를 이용하면 한 오브젝트가 다른 오브젝트를 참조하는 방식으로 둘 사이에 관계를 만들 수 있다.

그리고 도메인 계층 내부에서 계층을 만들어 도메인의 기능을 분할해줄 수도 있다. 크게 Model(Entity)라고 불리는 도메인과 데이터 전송을 위한 도메인인 DTO(Data Transfer Object)로 나눌 수 있다. 그렇게 되면 도메인 모델과 설계에 변경이 발생했을 때 보다 유연한 대처가 가능해진다[참조]

 

 

 

 

이번 스터디 프로젝트가 User 정보를 h2db에 새로운 User정보를 받아서 저장하고 id를 통해 하나의 정보 혹은 전체 정보를 들고올 수 있어야한다.

말만 들었을 때는 쉬워보이지만...

[찡찡1] User에 롬복을 사용하지 않고 빌더패턴을 구현하고(사실 롬복은 사용해본적도 없고 스터디에서 처음 들었뜸)

[찡찡2] 저장할 때의 요청JSON:{“principal”:“이메일”,“credentials”:“패스워드"}과 DB에서 데이터를 받아올 때 들고오는 응답JSON:{“success”:true,“response”:“가입완료"}이 달라서 DTO 구현해줘야하고

[찡찡3] Domain Driven Design으로 최대한 만들라구 해서.. Email은 String이 아니라 별도의 Value Object를 만들어줘야할 것같구..

[찡찡4] Junit테스트도 처움이구우ㅜ...

 

또 없나.. 아무튼 나중에 생각나면 더 써야징..

 

난 아직 Spring 바보라서 이런 작은 프로젝트도 UML을 그려봐야 조금 더 이해가 간다..

 

살짝 아까 언급했던 3계층 아키텍쳐와 오브젝트 중심 아키텍쳐를 합친 느낌이다.

 

 

사실 맞는지 잘 모르겠지만 허허 일단 이거대로 가보련다 허허

 

사실 여기다 쓰고싶은 내용들이 많은데 일단 과제부터 하러가야해서 이만 줄인당

나중에 지혜가 다시 여기다가 내용을 추가할 날이 오길 바라며..

지혜 파이티잉