..

항해 백엔드 코스 4주차 회고

#항해99 #항해플러스 #WIL

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

이번 주차를 지나며 겪었던 문제가 무엇이었나요?

Layerd 아키텍처의 적용

  • 여러 도메인으로 나뉘어져 있을때의 적용과 위반하지 않도록 하는 것이 가장 어려웠다.

계층간의 데이터 전송할때 dto를 작성하는 것

  • 계층을 옮길때 dto의 내용이 비슷하거나 같은 경우가 많았는데, 함수마다 작성하는게 좀 아쉬웠다.

2. 시도

문제를 해결하기 위해 어떤 시도를 하셨나요?

각 레이어에 위치해야할 파일들을 정리하고, 그 안에서의 역활을 작성해봤다.

// Presentation
module
controller : 요청  Facade 호출
dto(request, response) : Request, Response 객체

// Applicaiton
Facade : 여러 service를 연결해서 비즈니스를 동작

// Domain
service :  도메인에서의 비즈니스 로직을 수행
props : facade에서 전달받을 input parameter
model : 도메인 레벨에서 사용할 model 객체

// infrastructure
entity : Database Table 객체
repository : 필요한 Database SQL 모음집

이 틀안에서 최대한 벗어나지 않게 하는 것에 초점을 뒀던 것 같다.

3. 해결

문제를 어떻게 해결하셨나요?

비즈니스 로직을 작성해야한다는 생각에 Serivce 부터 작성을 했었는데, 오히려 Facade 객체부터 작성하면서 Top-Down 방식으로 진행하는게 더 편하다고 생각했다. Facade를 작성할때 필요한 서비스 목록이 나오고, 그 서비스 구현을 위한 repository들이 나오고 하는 형식으로 진행했다.

4. 알게된 것

문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요?

이전에 비즈니스 로직에 if문이 없는게 이상적이다 라는 이야기가 있었는데, 각 service들에서 그런 역활을 해주니까 Facade에서는 가져다 쓰고 연결해주기만 하면 되는구나! 그래서 전체 비즈니스 로직이 facade에서 한눈에 보일 수 있는 것 같다.


Keep : 현재 만족하고 계속 유지할 부분

이번 주를 마무리 하며 나에게 만족했던 부분은 무엇인가요?

계속 어려워하던 Layered 아키텍처의 틀을 잡았다는 점. 파일들의 위치와 역활이 계속 혼란스러웠는데, 어느정도 잡히니까 술술 작성할 수 있었다.

Problem : 개선이 필요하다고 생각하는 문제점

이번 주를 마무리 하며 개선이 필요하다고 생각했던 문제점은 무엇인가요?

계층간 데이터 전달시에 props의 네이밍이 명확하지 못했던 것. 중복이 아깝다고 생각할 시간에 불편해도 명확하게 해보자

Try : 문제점을 해결하기 위해 시도해야 할 것

이 문제점을 해결하기 위해 다음 한 주간 시도 할 것은 무엇인가요?

class, type의 네이밍을 명확하게 해보자! 너무 길지 않으면서 보기 편하게 작성하는 방법이 무엇일지 고민해보면 좋을 것 같다.