<div id="readability-page-1" class="page"><div>
    <h2 id="value-object-값-객체"><span>Value Object (값 객체)</span><a href="#value-object-값-객체"><i></i></a></h2>

<p><a href="https://user-images.githubusercontent.com/25674959/210389274-b436b4c4-e1d9-4e53-a553-1d9fdb4bcce7.png"><img src="https://user-images.githubusercontent.com/25674959/210389274-b436b4c4-e1d9-4e53-a553-1d9fdb4bcce7.png" width="500" loading="lazy"></a></p>



<p>도메인 개념을 모델링할 때</p>
<ol>
  <li>엔티티</li>
  <li><strong>값 객체</strong></li>
</ol>



<p>개념 모델링 시 유비쿼터스 언어를 활용할 것</p>

<ul>
  <li>서비스에서 사용되는 개념 / 용어 인지 ?</li>
  <li>기획 / 앱 개발자들도 해당 개념을 인지하고 있는지 ?</li>
</ul>



<h3 id="value-object"><span><strong>Value Object?</strong></span><a href="#value-object"><i></i></a></h3>

<ul>
  <li>도메인 내에서 측정 / 설명이 가능한 어떤 것
    <ul>
      <li>측정: 사람의 나이 (Age)</li>
      <li>설명: 사람의 이름 (Name)</li>
    </ul>
  </li>
  <li>불변성이 유지된다</li>
  <li>관련 특성을 모은 필수 단위이다 (응집)
    <ul>
      <li>Address: 도시 + 구 + 동 + 아파트 + 호수</li>
      <li>Time: count(0~60) + 단위(초/분/시간)</li>
    </ul>
  </li>
  <li>측정 / 설명이 변경될 때 완벽히 대체 가능
    <ul>
      <li>사람의 나이가 변경되면 새로운 값객체로 완전히 대체</li>
    </ul>
  </li>
  <li>다른 값과 등가성 비교 가능
    <ul>
      <li>모든 특성이 같다면 등가로 간주한다</li>
    </ul>
  </li>
  <li>Side Effect Free Function
    <ul>
      <li>불변성인 값객체의 메소드는 반드시 고유 상태를 변경하지 않아야 한다</li>
      <li>Q) 메서드 매개변수로 엔티티가 존재하고, 해당 엔티티를 수정하는 경우
        <ul>
          <li>바람직하지 않다. 테스트 어렵다. 해당 엔티티가 메서드를 가지도록 고려해볼 것</li>
          <li>매개변수로는 오직 값 만을 전달 -&gt; 부작용 없는 메서드 Good</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>



<h3 id="업스트림으로-부터-받아온-데이터는-entity-vo-dto"><span>업스트림으로 부터 받아온 데이터는 Entity? VO? DTO?</span><a href="#업스트림으로-부터-받아온-데이터는-entity-vo-dto"><i></i></a></h3>

<p>배달을 가기 위해서는 음식이 필요하다.</p>

<p>치킨을 건네받은 배달부는 이게 크크크치킨인지 호랑이치킨인지 모른다.</p>

<p>물론 치믈리에라면 냄새로 구분할 수 있겠지만, 배달부 입장에서는 치킨인지 조차 알 필요가 없다.</p>



<p>이처럼 다운스트림에서는 업스트림으로부터 모든 데이터를 알 필요가 없다.</p>

<p>다운스트림에서 필요한 데이터만 업스트림에 요청하면 되고,</p>

<p>다운스트림에서 받은 데이터는 각자 자신의 도메인 로직에 맞게 재구성된다.</p>

<p>다운스트림에서 도메인 로직 수행을 위해서 업스트림으로부터 데이터를 받아온 경우에도</p>

<p>해당 데이터에 대해 모델링을 잘 해야 한다.</p>



<p>업스트림으로부터 받은 데이터는 엔티티 일까? DTO 일까? 값객체 일까?</p>

<ul>
  <li>엔티티?
    <ul>
      <li>업스트림으로부터 받아온 데이터를 다운스트림에서도 해당 데이터에 대해 주기적으로 트래킹해야하는 경우 엔티티로 만들 것 같다</li>
      <li>다운스트림에서는 엔티티로 표현하고. 업스트림의 이벤트를 받아서 다운스트림 엔티티를 갱신하려나?</li>
    </ul>
  </li>
  <li>DTO?
    <ul>
      <li>데이터를 담은 그릇일까? 도메인 정보를. 유비쿼터스 언어를 잘 표현하지 못하는 것 같다.</li>
      <li>업스트림으로부터 받아온 데이터이지만, 도메인 관련 메서드를 표현해야 할 수도 있다.</li>
    </ul>
  </li>
  <li>값객체
    <ul>
      <li>업스트림으로부터 받아온 데이터가 다운스트림에서 주기적으로 트래킹 하지 않는다면 값객체로 만들 것 같다</li>
      <li>업스트림으로 부터 받아온 데이터이지만, 이 데이터들도 다운스트림에서의 유비쿼터스 언어로 표현할 수 있는 개념이 있을 것이고, 메서드도 만들어볼 수 있을 듯</li>
    </ul>
  </li>
</ul>



<h3 id="값-객체vo-vs-기본-언어-값-타입-string-int-등"><span>값 객체(VO) vs 기본 언어 값 타입 (String, Int 등)</span><a href="#값-객체vo-vs-기본-언어-값-타입-string-int-등"><i></i></a></h3>

<p>관련 특성이 두개 이상인 경우에는 값객체로 만들겠지만, 만약 관련특성이 한개 뿐이라면.. 기존 언어 값 타입을 값객체로 만들어야 할까?</p>

<ul>
  <li>VO +1점: VO에는 도메인에 맞는 메서드를 추가할 수 없다. 예외적인 상황도 이해할 수 있다. 도메인 이해도 증가
    <ul>
      <li>이름은 2~3 글자, 한글만 가능하구나</li>
      <li>나이는 100살을 넘을 수 없구나</li>
    </ul>
  </li>
  <li>VO +1점: 학습 테스트를 짤 수 있다. 도메인 이해도 증가</li>
  <li>VO -1점: 만들기 귀찮다</li>
</ul>



<p>TODO 보강</p>


  </div></div>

Value Object (값 객체)

댓글