<div id="readability-page-1" class="page"><div><h3 id="오탈자">오탈자</h3>
<ul>
 <li>p.125 코드 <code>if (account.isBlocked())</code> -&gt; <code>if (store.isBlocked())</code></li>
</ul>

<hr>

<h3 id="1-도메인-모델-시작하기">1. 도메인 모델 시작하기</h3>

<ul>
 <li>p.33 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.</li>
 <li>p.35 도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다.</li>
 <li>p.46 Value 타입은 개념적으로 완전한 하나를 표현할 때 사용한다.</li>
 <li>p.50 Value 타입을 불변으로 구현하는 여러 이유가 있는데 가장 중요한 이유는 안전한 코드를 작성할 수 있다는 데 있다.</li>
</ul>

<div><pre><code>data class Money(val value: Int)
data class OrderLine(
 val product: Product,
 val price: Money,
 val quantity: Int,
 val amounts: Money,
)
</code></pre></div>

<ul>
 <li>p.52 식별자는 단순한 문자열이 아니라 도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 Value 타입을 사용해서 의미가 잘 드러나도록 할 수 있다.</li>
</ul>

<div><pre><code>public class Order {
 private OrderNo id;
 ...
 public OrderNo getId() {
 return id;
 }
}
</code></pre></div>

<ul>
 <li>p.55 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다. 즉 생성자를 통해 필요한 데이터를 모두 받아야 한다.</li>
 <li>p.58 에릭 에반스는 도메인 주도 설계에서 언어의 중요함을 강조하기 위해 유비쿼터스 언어라는 용어를 사용했다. 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용한다. 이렇게 하면 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.</li>
</ul>

<hr>

<h3 id="2-아키텍처-개요">2. 아키텍처 개요</h3>

<ul>
 <li>p. 63 Application 서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.</li>
</ul>

<div><pre><code>class CancelOrderService {
 @Transactional
 fun cancelOrder(orderId: String) {
 val order = findById(orderId) ?: throw OrderNotFoundException(orderId)
 // 주문 취소 로직을 직접 구현하지 않고 Order 객체에 취소 처리를 위임
 order.cancel()
 }
 ...
}
</code></pre></div>

<ul>
 <li>p.64 인프라스트럭처 영역은 논리적인 개념을 표현하기보다는 실제 구현을 다룬다. 도메인 영역, Application 영역, Presentation 영역은 구현 기술을 삳용한 코드를 직접 만들기 않는다. 대신 인프라스트럭처 영역에서 제공하는 기능을 사용해서 필요한 기능을 개발한다.</li>
 <li>p.69 인프라스트럭처에 의존하면 ‘테스트 어려움’과 ‘기능 확장의 어려움’이라는 두 가지 문제가 발생하는 것을 알게 되었다. 그렇다면 어떻게 해야 이 두 문제를 해소할 수 있을까? 해답은 DIP에 있다.</li>
 <li>p.70 고수준 모듈이 제대로 동작하려면 저수준 모듈을 사용해야 한다. 그런데 고수준 모듈이 저수준 모듈을 사용하면 앞서 계층 구조 아키텍처에서 언급했던 두 가지 문제, 즉 구현 변경과 테스트가 어렵다는 문제가 발생한다.</li>
 <li>p.71 DIP는 이 문제를 해결하기 위해 저수준 모듈과 고수준 모듈에 의존하도록 바꾼다. 저수준 모듈을 구현하려면 저수준 모듈을 사용해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존하도록 하려면 어떻게 해야 할까? 비밀은 추상화한 인터페이스에 있다.</li>
 <li>p.73 고수준 모듈이 저수준 모듈을 사용하려면 고수준 모듈이 저수준 모듈에 의존해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존한다고 해서 이를 DIP Dependency Inversion Principle , 의존 역전 원칙이라고 부른다.</li>
 <li>p.75 실제 구현 없이 테스트를 할 수 있는 이유는 DIP를 적용해서 고수준 모듈이 저수준 모듈에 의존하지 않도록 했기 때문이다.</li>
 <li>p.77 인프라스트럭처 영역은 구현 기술을 다루는 저수준 모듈이고 Application 영역과 도메인 영역은 저수준 모듈이다. 인프라스트럭처 계층이 가장 하단에 위치하는 계층형 구조와 달리 아키텍처에 DIP를 적용하면 인프라스트럭처 영역이 Application 영역과 도메인 영역에 의존(상속)하는 구조가 된다.</li>
</ul>

<img src="https://sungjk.github.io/images/2022/03/27/dip.png" alt="dip" title="dip">

<ul>
 <li>p.80 도메인 영역의 주요 구성요소
 <ul>
 <li>엔티티(Entity): 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.</li>
 <li>밸류(Value): 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소(Address)나 구매 금액을 위한 금액(Money)와 같은 타입이 Value 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 Value 타입의 속성으로도 사용할 수 있다.</li>
 <li>애그리거트(Aggregate): 애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.</li>
 <li>리포지터리(Repository): 도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.</li>
 <li>도메인 서비스(Domain service): 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. ‘할인 금액 계산’은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.</li>
 </ul>
 </li>
 <li>p.81 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다는 점이다. 도메인 모델의 에티티는 단순히 데이터를 담고 있는 데이터 구조라기보다는 데이터와 함께 기능을 제공하는 객체이다. 도메인 관점에서 기능을 구현하고 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.</li>
 <li>p. 84 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데 도움이 된다. 도메인 모델에서 전체 구조를 이해하는 데 도움이 되는 것이 바로 애그리거트 Aggregate 이다.</li>
 <li>p.85 애그리거트는 군집에 속한 객체를 관리하는 루트 엔티티를 갖는다. 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다. 애그리거트를 사용하는 코드는 애그리거트가 제공하느 기능을 실행하고 애그리거트 루트를 통해서 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근한다. 이것은 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.</li>
</ul>

<img src="https://sungjk.github.io/images/2022/03/27/aggre_root.png" alt="aggre_root" title="aggre_root">

<ul>
 <li>p.88 Application 서비스와 리포지터리는 밀접한 연관이 있다.
 <ul>
 <li>Application 서비스는 필요한 도메인 객체를 구하거나 저장할 때 리포지터리를 사용한다.</li>
 <li>Application 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술의 영향을 받는다.</li>
 </ul>
 </li>
</ul>

<hr>

<h3 id="3-애그리거트">3. 애그리거트</h3>

<ul>
 <li>p.99 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 그 방법이 바로 애그리거트다.</li>
 <li>p.100 모델을 보다 잘 이해할 수 있고 애그리거트 단위로 일관성을 관리하기 때문에, 애그리거트는 복잡한 도메인을 단순한 구조로 만들어준다. 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.</li>
 <li>p.101 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.</li>
 <li>p.103 애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티다. 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.</li>
 <li>p.104 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다. 애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다.</li>
 <li>p.106 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들려면, 도멩니 모델에 대해 다음의 두 가지를 습관적으로 적용해야 한다.
 <ul>
 <li>단순히 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.</li>
 <li>밸류 타입은 불변으로 구현한다.</li>
 </ul>
 </li>
 <li>p.107 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능하다. 그러므로 애그리거트 루트가 도메인 규칙을 올바르게만 구현하면 애그리거트 전체의 일관성을 올바르게 유지할 수 있다.</li>
 <li>p.109 트랜잭션 범위는 작을수록 좋다. 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생한다. 한 개 테이블을 수정하면 트랜잭션 충돌을 막기 위해 잠그는 대상이 한 개 테이블의 한 행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아진다. 잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고 이것은 전체적인 성능(처리량)을 떨어뜨린다.</li>
 <li>p.110 한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 의미한다. 한 애그리거트에서 다른 애그리거트를 수정하면 결과적으로 두 개의 애그리거트를 한 트랜잭션에서 수정하게 되므로, 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안 된다.</li>
 <li>p.110 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고 Application 서비스에서 두 애그리거트를 수정하도록 구현한다.</li>
</ul>

<div><pre><code>class ChangeOrderService {
 // 두 개 이상의 애그리거트를 변경해야 한면,
 // Application 서비스에서 각 애그리거트의 상태를 변경한다.
 @Transactional
 fun changeShipping(id: OrderId, newShipping: Shipping, useNewShppingAddr: Boolean) {
 val order = orderRepository.findById(id) ?: throw OrderNotFoundException(id)
 order.shipTo(newShpping)
 if (useNewShppingAddr) {
 val member = findMember(order.getOrderer())
 member.changeAddress(newShpping.getAddress())
 }
 }
}
</code></pre></div>

<ul>
 <li>p.113 애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 애그리거트에서 두 개의 객체를 변경했는데 저장소에는 한 객체에 대한 변경만 반영되면 데이터 일관성이 깨지므로 문제가 된다.</li>
 <li>p.115 한 애그리거트 내부에서 다른 애그리거트 객체를 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다. 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다. 그런데 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 구현의 편리함 때문에 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.</li>
 <li>p.116 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.</li>
 <li>p.117 ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다. 또한 애그리거트 간의 의존을 제거하므로 응집도를 높여주는효과도 있다.</li>
</ul>

<div><pre><code>public class Order {
 private Orderer orderer;
 ...
}
public class Orderer {
 private MemberId memberId;
 private String name;
 ...
}
public class Member {
 private MemberId id;
 ...
}
</code></pre></div>

<ul>
 <li>p.118 ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다. 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.</li>
 <li>p.119 ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다.</li>
 <li>p.127 애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해보자.</li>
 <li>p.127 다른 팩토리에 위임하더라도 차단 상태의 상점은 상품을 만들 수 없다는 도메인 로직은 한곳에 계속 위치한다.</li>
</ul>

<div><pre><code>class Store {
 fun createProduct(newProductId: ProductId, product: ProductInfo): Product {
 if (isBlocked()) {
 throw StoreBlockedException()
 }
 return ProductFactory.create(newProductId, getId(), product)
 }
}
</code></pre></div>

<hr>

<h3 id="참고">참고</h3>
<ul>
 <li><a href="http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&amp;ejkGb=KOR&amp;barcode=9791162245385&amp;orderClick=LA6">도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지</a></li>
</ul>
</div></div>

coyled.com

Jeremy Kim

오탈자
p.125 코드 if (account.isBlocked()) -> if (store.isBlocked())
1. 도메인 모델 시작하기
p.33 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.
p.35 도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다.
p.46 Value 타입은 개념적으로 완전한  하나를 표현할 때 사용한다.
p.50 Value 타입을 불변으로 구현하는 여러 이유가 있는데 가장 중요한 이유는 안전한 코드를 작성할 수 있다는 데 있다.
data class Money(val value: Int)
data class OrderLine(
  val product: Product,
  val price: Money,
  val quantity: Int,
  val amounts: Money,
)
p.52 식별자는 단순한 문자열이 아니라 도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 Value 타입을 사용해서 의미가 잘 드러나도록 할 수 있다.
public class Order {
  private OrderNo id;
  ...
  public OrderNo getId() {
    return id;
  }
}
p.55 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다. 즉 생성자를 통해 필요한 데이터를 모두 받아야 한다.
p.58 에릭 에반스는 도메인 주도 설계에서 언어의 중요함을 강조하기 위해 유비쿼터스 언어라는 용어를 사용했다. 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용한다. 이렇게 하면 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.
2. 아키텍처 개요
p. 63 Application 서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.
class CancelOrderService {
  @Transactional
  fun cancelOrder(orderId: String) {
    val order = findById(orderId) ?: throw OrderNotFoundException(orderId)
    // 주문 취소 로직을 직접 구현하지 않고 Order 객체에 취소 처리를 위임
    order.cancel()
  }
  ...
}
p.64 인프라스트럭처 영역은 논리적인 개념을 표현하기보다는 실제 구현을 다룬다. 도메인 영역, Application 영역, Presentation 영역은 구현 기술을 삳용한 코드를 직접 만들기 않는다. 대신 인프라스트럭처 영역에서 제공하는 기능을 사용해서 필요한 기능을 개발한다.
p.69 인프라스트럭처에 의존하면 ‘테스트 어려움’과 ‘기능 확장의 어려움’이라는 두 가지 문제가 발생하는 것을 알게 되었다. 그렇다면 어떻게 해야 이 두 문제를 해소할 수 있을까? 해답은 DIP에 있다.
p.70 고수준 모듈이 제대로 동작하려면 저수준 모듈을 사용해야 한다. 그런데 고수준 모듈이 저수준 모듈을 사용하면 앞서 계층 구조 아키텍처에서 언급했던 두 가지 문제, 즉 구현 변경과 테스트가 어렵다는 문제가 발생한다.
p.71 DIP는 이 문제를 해결하기 위해 저수준 모듈과 고수준 모듈에 의존하도록 바꾼다. 저수준 모듈을 구현하려면 저수준 모듈을 사용해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존하도록 하려면 어떻게 해야 할까? 비밀은 추상화한 인터페이스에 있다.
p.73 고수준 모듈이 저수준 모듈을 사용하려면 고수준 모듈이 저수준 모듈에 의존해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존한다고 해서 이를 DIP Dependency Inversion Principle , 의존 역전 원칙이라고 부른다.
p.75 실제 구현 없이 테스트를 할 수 있는 이유는 DIP를 적용해서 고수준 모듈이 저수준 모듈에 의존하지 않도록 했기 때문이다.
p.77 인프라스트럭처 영역은 구현 기술을 다루는 저수준 모듈이고 Application 영역과 도메인 영역은 저수준 모듈이다. 인프라스트럭처 계층이 가장 하단에 위치하는 계층형 구조와 달리 아키텍처에 DIP를 적용하면 인프라스트럭처 영역이 Application 영역과 도메인 영역에 의존(상속)하는 구조가 된다.
p.80 도메인 영역의 주요 구성요소
    
엔티티(Entity): 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.
밸류(Value): 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소(Address)나 구매 금액을 위한 금액(Money)와 같은 타입이 Value 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 Value 타입의 속성으로도 사용할 수 있다.
애그리거트(Aggregate): 애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.
리포지터리(Repository): 도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.
도메인 서비스(Domain service): 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. ‘할인 금액 계산’은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.
p.81 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다는 점이다. 도메인 모델의 에티티는 단순히 데이터를 담고 있는 데이터 구조라기보다는 데이터와 함께 기능을 제공하는 객체이다. 도메인 관점에서 기능을 구현하고 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.
p. 84 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데 도움이 된다. 도메인 모델에서 전체 구조를 이해하는 데 도움이 되는 것이 바로 애그리거트 Aggregate 이다.
p.85 애그리거트는 군집에 속한 객체를 관리하는 루트 엔티티를 갖는다. 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다. 애그리거트를 사용하는 코드는 애그리거트가 제공하느 기능을 실행하고 애그리거트 루트를 통해서 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근한다. 이것은 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.
p.88 Application 서비스와 리포지터리는 밀접한 연관이 있다.
    
Application 서비스는 필요한 도메인 객체를 구하거나 저장할 때 리포지터리를 사용한다.
Application 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술의 영향을 받는다.
3. 애그리거트
p.99 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 그 방법이 바로 애그리거트다.
p.100 모델을 보다 잘 이해할 수 있고 애그리거트 단위로 일관성을 관리하기 때문에, 애그리거트는 복잡한 도메인을 단순한 구조로 만들어준다. 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
p.101 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
p.103 애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티다. 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.
p.104 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다. 애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다.
p.106 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들려면, 도멩니 모델에 대해 다음의 두 가지를 습관적으로 적용해야 한다.
    
단순히 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.
밸류 타입은 불변으로 구현한다.
p.107 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능하다. 그러므로 애그리거트 루트가 도메인 규칙을 올바르게만 구현하면 애그리거트 전체의 일관성을 올바르게 유지할 수 있다.
p.109 트랜잭션 범위는 작을수록 좋다. 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생한다. 한 개 테이블을 수정하면 트랜잭션 충돌을 막기 위해 잠그는 대상이 한 개 테이블의 한 행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아진다. 잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고 이것은 전체적인 성능(처리량)을 떨어뜨린다.
p.110 한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 의미한다. 한 애그리거트에서 다른 애그리거트를 수정하면 결과적으로 두 개의 애그리거트를 한 트랜잭션에서 수정하게 되므로, 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안 된다.
p.110 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고 Application 서비스에서 두 애그리거트를 수정하도록 구현한다.
class ChangeOrderService {
  // 두 개 이상의 애그리거트를 변경해야 한면,
  // Application 서비스에서 각 애그리거트의 상태를 변경한다.
  @Transactional
  fun changeShipping(id: OrderId, newShipping: Shipping, useNewShppingAddr: Boolean) {
    val order = orderRepository.findById(id) ?: throw OrderNotFoundException(id)
    order.shipTo(newShpping)
    if (useNewShppingAddr) {
      val member = findMember(order.getOrderer())
      member.changeAddress(newShpping.getAddress())
    }
  }
}
p.113 애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 애그리거트에서 두 개의 객체를 변경했는데 저장소에는 한 객체에 대한 변경만 반영되면 데이터 일관성이 깨지므로 문제가 된다.
p.115 한 애그리거트 내부에서 다른 애그리거트 객체를 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다. 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다. 그런데 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 구현의 편리함 때문에 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.
p.116 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
p.117 ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다. 또한 애그리거트 간의 의존을 제거하므로 응집도를 높여주는효과도 있다.
public class Order {
  private Orderer orderer;
  ...
}
public class Orderer {
  private MemberId memberId;
  private String name;
  ...
}
public class Member {
  private MemberId id;
  ...
}
p.118 ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다. 외부 애그리거트를 직접 참조하지 않기  때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.
p.119 ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다.
p.127 애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해보자.
p.127 다른 팩토리에 위임하더라도 차단 상태의 상점은 상품을 만들 수 없다는 도메인 로직은 한곳에 계속 위치한다.
class Store {
  fun createProduct(newProductId: ProductId, product: ProductInfo): Product {
    if (isBlocked()) {
      throw StoreBlockedException()
    }
      return ProductFactory.create(newProductId, getId(), product)
  }
}
참고
도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지

도메인 주도 개발 시작하기

댓글