콘텐츠로 이동

2021 04 22 설계

2021-04-22 설계

DTO

  • DTO가 뭔가요? - 계층 간 데이터 교환을 위한 객체입니다. - 계층 간에 정말 필요한 데이터만 뽑아 만든 객체로, getter와 setter만 가지고, 비즈니스 로직은 가지지 않습니다. - 가령 DB의 데이터를 Service로 보내거나, Controller와 View간의 데이터를 주고 받을 때 사용됩니다.
  • 왜 DTO가 필요했죠? 그냥 그 자체로 넘기면 안되나요? 파싱하고 말이죠 - 저는 DTO가 각 레이어 간의 객체를 보호하기 위해서 사용될 수 있다고 생각합니다. - 상태와 행위를 고스란히 간직하고 있는 객체를 여러 레이어를 통해 공유하면, 엉뚱한 레이어에서 객체들이 조작되는 문제들이 발생할 수 있습니다. - 따라서, getter와 setter만 있는 DTO를 만들어 해당 문제를 해결할 수 있습니다. - Layer간에 필요한 데이터의 약속만 서로 안다면, 정보를 안전하게 교환할 수 있게됩니다. - 가령 View단과 Controller단에서 JSON으로만 데이터를 주고 받을 수도 있죠. - 그렇다면 JSON으로 주고 받을 수 있도록 DTO를 작성할 필요가 있습니다.
  • DTO를 씀으로써 얻은 장단점이 무엇인가요? - 레이어 간의 중요 비즈니스 로직을 담은 객체를 보호할 수 있어요. - 예를 들어 체스 미션에서 DTO로써 chessgame 도메인 객체 중 view에서 보여줄 필요한 정보만을 뽑아 DTO를 만들 수 있었어요. - chessgame 객체를 고스란히 넘겨주게 되면, 해당 객체는 상태와 행위를 모두 제어할 수 있는 도메인 객체가 넘어가게 되는데, - 이는 불필요한 문제들을 발생시킬 수 있어요. - 데이터 교환을 Map이나 String같은 자료구조로 못하나요? - 아니요 할 수 있습니다. - 하지만 이는 코드의 가독성과 관련있다고 생각합니다. - 유지/보수가 유리한 코드를 작성하기 위해서는 코드를 읽으면 의도가 파악되는 것이 중요하다고 생각하는데, - DTO를 명시함으로써, 다른 레이어에서 넘어온 데이터임을 알 수 있고, - 도메인 객체를 있는 그대로 넘겨 조작의 위험성을 그대로 노출시키는 것이 아닌, - 필요한 정보만을 담은 DTO를 레이어로 넘겨 도메인 객체를 보호할 수도 있습니다.
  • DTO와 VO를 비교해주세요 - DTO는 계층 간 데이터 교환을 위한 객체이고, VO는 도메인 객체 중 한 개 혹은 그 이상의 값을 묶어 특정값을 표현하기 위한 객체입니다.

VO

  • VO가 뭐죠? - 도메인에서 한 개 또는 그 이상의 속성들을 묶어 특정값을 나타내는 객체입니다.
  • VO를 정의하기 위해 해야하는 것? 1. equals & hashCode를 재정의할 것 - 값을 나타내는 객체이며, 값이 모든 식별자 - 즉 값이 같다면 동등한 객체로 판단해야함. - hashCode와 equals를 오버라이딩 하자 2. Setter가 없는 불변객체여야한다. - 속성값 자체가 식별자 역할을 하기 때문에, 한번 설정 이후 변동되면 안됨
  • VO와 원시값 포장의 다른점? - 객체 자체를 값으로 보기 위해 만든것이 VO - 원시값 포장은, 이를 통해 책임을 분리시키려는 의도
  • VO를 썼던 경험? - Position(x,y)를 통해 체스게임의 좌표를 표현한 적이 있었습니다.
  • VO를 쓰면서 얻은 인사이트? - 우선 VO는 비즈니스 로직을 가질 수 있어요. - 상태와 행위를 제어할 수 있으니, 이는 앞서 언급한 일급컬렉션, 원시값 포장등과 같이 하나의 책임과 역할을 가진 응집도 높은 클래스 설계로 이어져요 - 자연스레 객체 지향적인 코드도 가질 수 있답니다. - 또한 VO를 쓰면서 느낀 장점은 캐싱에 용이하다는 것이에요. - VO는 나타내려는 값이 같다면, 동등한 객체로 인지해요. - 또한 "값"이 너무나도 중요한 필드이고, 유일하게 이를 구별할 수 있는 기준이 되기에, 값은 불변으로 만들게 되어요. - 전 이런 VO의 특징들을 이용하여, 체스게임에서 필요한 VO들을 미리 정의하고 캐싱해 둘 수 있었어요.

Service Layer

  • 웹 아키텍쳐 레이어를 설명해보세요 1. Presentation Layer (UI layer) - 사용자와의 인터페이스 담당 - 사용자가 보는 화면과, API 요청을 처리하는 컨트롤러의 역할이라고 할 수 있다 2. Service Layer (Application layer) - Domain Model들을 묶어 SW에서 사용가능한 핵심 작업 집합을 설정하는 계층 - 즉, SW가 수행해야 하는 작업을 명시하는 계층 - 비즈니스 로직들을 의미있는 수준으로 묶어 제공하는 역할 담당 3. Business Layer (Domain Model) - 데이터와 그와 관련된 비즈니스 로직을 가지고 있는 객체 4. Persistent Layer - Data Source를 추상화 시킴 - 요청/응답 데이터를 비즈니스 로직에서 필요한 데이터로 가공하여 변환해 비즈니스 레이어로 넘겨주어야 함 - 어라 닉은 Dao에서 그냥 DB 접근만 하랬는데...?
  • 서비스 레이어는 뭔가요? - 서비스 레이어는 도메인 모델의 비즈니스 로직을 의미있는 수준으로 묶어, 해당 프로그램에서 사용가능한 핵심 작업을 수행하는 레이어입니다.
  • 왜 필요하죠? - 우선 레이어를 분리하면서 "추상화"를 시킬 수 있어요. - 마치 객체지향 프로그램 처럼, 추상화를 잘 시킨 레이어는, 주어진 책임과 역할을 완수한다면, 부품을 갈아끼우듯 변경할 수 있어요. - 각 레이어가 자신의 세부사항을 몰라도 상관없도록 추상화해서 제공하면 말이죠 - 컴포넌트들의 서로의 의존 계층 관계를 깔끔히 유지할 수 있어요. - 위에서 아래로 떨어지는 깔끔한 구조로 말이에요.
  • 그냥 도메인에서 처리해주는거랑 뭔 차이죠? - 비즈니스 로직들은 사실 도메인에서 처리해주고, 서비스 레이어는 얇게 구성하는 것이 좋다고 합니다. - 하지만 사실 서비스 레이어를 접해본지 얼마 안되, 직접 느낀 사례는 없습니다. - 다만 추측하건데, 도메인이 각자의 역할과 책임을 온전히 잘 수행하도록 작성이 되었다면, 서비스 레이어는 자연스레 얇게 유지될 것이라 생각됩니다. - 그냥 요청을 위임하고 응답만 받는 형식으로요.