[우아한테크코스 5기] 지하철 1단계 학습로그

---

들어가며

GitHub저장소

구현 기능들

궁금한 것

코드 리뷰

후기

---

📆 기간 : 2023.05.09 - 2023.05.11

뛰뛰빵빵

---

들어가며

지하철 미션은 여우와 페어가 되었다. 하지만 여우가 목이 많이 아픈관계로 ㅠㅠ 페어를 못하겠다고 하였고 나는 나의 새로운 짝을 찾아 나서는 방법밖에 없었다.. 그렇게 내가 찾은 나의 페어는 우가, 쥬니였다. 친한 데일리 크루들인 만큼 같이 하면 재밌고 신나게 할 수 있을 것 같았다. 3인페어가 처음이였지만 재미있었다. 의견 충돌이 나더라도 인원수가 홀수 이다보니 쉽게 결정할 수 있었다. 우가랑 쥬니 모두 잘 하는 크루들이여서 잘 마무리 했던 것 같다. 비록 마지막엔 조금 급했지만 .. 

---

GitHub 저장소

지하철 1단계 PR 깃허브 주소

GitHub - woowacourse/jwp-subway-path

---

구현 기능 목록

도메인과 엔티티 분리

먼저 도메인과 엔티티를 분리하였다. 분리한 이유는 다음과 같다.

이를 분리해서 가져가는 것에 대한 장점으로는 도메인 변경이 유연하여 확장하기에 용이한점, db의 변화가 entity에 그친다는 점, 계층간 분리가 잘 되는 점. 단점으로는 변환로직이 너무 많아서 가독성이 떨어지는 점, 복잡하고 domain-entity간 추가적인 코드 작성이 많은 점. 이였던 것 같은데 객체 지향적으로 작성해보기 위해 도메인과 엔티티를 분리하였다. 레벨1에서 이렇게 진행했기에 레벨2의 도메인도 비슷한 방식으로 진행하면 좋을 것 이라고 생각하였다.

Spring에서 도메인의 비즈니스로직이 이렇게 많은 상태에서 해보긴 처음이라 어려웠던 것 같다.

 

내가 생각한 프로세스는 Request -> Controller -> Service -> Domain -> Service -> Entity -> Dao 와 같은 과정이였다. 이렇다 보니 Domain -> Entity, Entity -> Domain 로직이 계속 존재할 수 밖에 없었고 가독성이 너무 떨어졌다..

그리고 db를 제외한 순수한 도메인 객체를 만들려고 하다 보니 더욱 어려웠던 것 같다. db를 고려해서 짜는 것은 불가피 하다고 생각하게 되었다. 

 

Line

라인은 라인에 대한 정보와 라인이 갖고있는 Sections를 가지고 있어야 한다고 생각했다.

private final LineInfo lineInfo;
private final Sections sections;

public Line(LineInfo lineInfo, Sections sections) {
    this.lineInfo = lineInfo;
    this.sections = sections;
}

반환시에도 이와 같은 값을 전달하게 하였다.

 

Section & Sections

section이란 시작역,도착역,거리 를 가지고 있는 묶음 이였다. 그리고 이것을 모두 관리하는 일급컬렉션이 Sections였다.

Sections에서 section의 추가, 삭제 등 역을 추가하고 삭제하고 정렬하고 모든 과정이 Sections의 비즈니스 로직이였다.

이걸 만든 이유는 Line이 Sections를 가지고 Sections가 Section을 가지게 함으로써 관리하기 쉽게 하려고 하였다.

Station

단순하게 역의 이름만 갖게 하였다.

---

궁금한 것

도메인이 ID를 갖는것은 DB중심 설계인가 ?

나의 처음 생각은 도메인이 ID를 갖는것은 db중심적이라고 생각했다. 왜나하면 이 domain의 id값이 auto-increment되는 값이라면 db의 의존적이라고 생각했기 때문이다. 물론 도메인의 유일성을 식별하는 필드는 필요하다고 생각한다. 

 

지금 생각하는 나의 의견은 도메인을 식별하는 필드가 필요하며, 순수한 도메인 객체 구성이 답은 아니고 db의 기술적인 현실적인 부분이 도메인 객체에 반영될 수 있다는 것이다.

 

Repository 분리

나는 이번에 레포지토리를 나누지 않았다. 나누지 않은 이유로는 Service단에서 Dao에 의존적이면 된다고 생각했다. Repository를 나누게 된다면 코드가 좀 더 깔끔해지고 domain<->entity간 mapper역할을 할 수 있는 클래스가 존재한다인데, service에서 충분히 해낼 수 있는 것을 나누는것에 크게 매력을 느끼지 못하였다.

 

여러번의 DB조회와 단일 조회

여러번의 db조회와 단일 조회 무조건 단일 조회가 옳은 것일까 ?

여러번 조회하는 경우는 필요한 데이터를 조합,필터하여 정확한결과를 사용할 수 있지만, db부하, 성능저하가 발생할 수 있다.

단일 조회하는 경우는 성능상의 이점을 가질 수 있다. 다만 데이터를 처리하거나 조합해야할때 추가적인 로직이 필요할 수 있다.

 

객체지향을 지킬 수 있을까 ?

처음에는 객체지향적으로 미션을 작성하고자 최대한 노력하였다. 하지만 점점 갈수록 객체지향보다는 db에 맞게 하는 것이 조금 더 쉬웠고 편했다.. 그래서 아직도 잘 모르겠당..

 

db값은 안전한가 ?

초기에 db에 들어가있는 값은 안전한가? 만약 안전하지 않다면 이것을 따로 검증을 해줘야 한다. 하지만 나는 db에 들어가있는 값은 안전하다고 생각해야된다는 주의이다. 내가 짠 코드에 버그가 있지 않는이상 안전하지 않은 값은 들어가지 않기 때문이다.

안전하지 않더라도 도메인 객체를 이용하면 검증이 될 것이다. db 값 -> 도메인 객체로 만드는 과정에서 유효성 검사가 되기 때문이다.

 

로직 수행 과정

이번 미션 로직 수행 과정은

Request -> controller -> service (domain 객체 구성을 위해 필요한 dao 값 호출) -> domain -> service -> entity -> dao 와 같은 로직이였다.

예시로 내가 section을 추가하려고 한다. 그럼 필요한 로직은

Line 을 db에서 가져와서 객체를 생성한다. -> 추가하려는 Section의 station을 db에 저장한다. -> Line의 Sections안에 section을 저장한다. -> Line의 Section을 db에 저장한다. 인데 이런 방식이 좋은지 모르겠다.

좋다고 생각하는 방법은 

추가하려는 Section의 station을 db에 저장한다. -> Line의 Section을 db에 저장한다. 인데 . . 이러면 도메인을 거의 안쓰는 것 같아서 고민이다...

---

나가며

2단계도 화이팅 ! 다음 미션도 화이팅 ! 레벨2 화이팅!