트랜잭션 범위

트랜잭션 범위

트랜잭션의 범위는 작을수록 좋다.

DB 테이블 기준으로 한 트랜잭션이 한 개의 데이터베이스를 수정하는 것과 세 개의 테이블을 수정하는 것은 성능에서 차이가 발생한다.

한 트랜잭션에는 한 개의 애그리거트만 수정해야한다.

애그리거트에서 다른 애그리거트를 변경하지 않는다는 뜻

예) 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능

public class Order { private Orderer orderer; public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddrAsMemberAddr) { verifyNotYetShipped(); setShippingInfo(newShippingInfo); if(useNewShippingAddrAsMemberAddr) { //다른 애그리거트의 상태를 변경하면 안된다. orderer.getCustomer().changeAddress(newShippingInfo.getAddress()); } } }

주문 애그리거트는 회원 애그리거트의 정보를 변경하면 안된다.

애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이된다. 애그리거트는 서로 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아지게 된다.

결합도가 높아지면 높아질수록 향후 수정 비용이 증가하므로 애그리거트에서 다른 애그리거트의 상태를 변경하지 말아야 한다.

부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 응용 서비스에서 두 애그리거트를 수정하도록 한다.

public class ChangeOrderService { @Transactional public void chanageShippingInfo(Order Id id, ShippingInfo newShippingInfo, boolean useNewShippingAddrAsMemberAddr) { Order order = orderRepository.findById(id); if(order == null) throw new OrderNotFoundException(); order.shipTo(newShippingInfo); if(useNewShippingAddrAsMemberAddr) { order.getOrderer().getCustomer().changeAddress(newShippingInfo.getAddress()); } } }

도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서도 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할수 도 있다.

한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 경우

1) 팀 표준

팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야하는 경우

DB가 다른 경우 글로벌 트랜잭션을 반드시 사용하도록 규칙을 정할 때

2) 기술제약

한 트랜잭션에서 두 개 이상의 애그리거트를 수정하는 대신 도메인 이벤트와 비동기를 사용하는 방식을 사용하는데, 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야한다.

3) UI 구현의 편리

운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 때, 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경할 때

리포지터리와 애그리거트

애그리거트는 개념상 완전한 한개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.

Order와 OrderLine을 물리적으로 각가 별도의 DB 테이블에 저장한다고 해서 Order와 OrderLine을 위한 리포지터리를 각각 만들지 않는다.

Order가 애그리거트 루트이고  OrderLine인 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재한다.

새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어와야 하므로 적어도 두개의 메서드를 제공해야한다.

1) save - 애그리거트 저장

2) findById - ID로 애그리거트를 구함

어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.

ORM 기술중의 하나인 JPA/하이버네이트를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 하는 경우도 있다.

특히 레거시 DB를 사용해야 하거나 팀 내 DB 설계 표준을 따라야 한다면 DB 테이블 구조에 맞게 모델을 변경해야한다.

이 경우 밸류 타입인 도메인 모델을(JPA에서 밸류 타입을 매핑할 때 사용하는 ) @Component 아닌(엔티티를 매핑할 때 사용하는 ) @Entity를 이용해야 할 수 도 있다.

애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야한다.

예들 들어, Order 애그리거트와 관련된 테이블이 세 개라면 리포지터리를 통해 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성 요소를 위한 테이블에 데이터를 저장해야 한다.

// 리포지터리에 애그리거트를 저장하면 애그리거트 전체를 영속화해야한다.

orderRepository.save(order);

애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야한다.

// 리포지터리는 완전한 order를 제공한다.

Order order = orderRepository.findById(orderId);

//order가 온전한 애그리거트가 아니면

//기능 실행 도중 NullPointException과 같은 문제가 발생

order.cancel();

저장소로 마리아DB나 오라클 같은 RDBMS뿐만 아니라 몽고DB, HBase와 같은 NoSQL도 함께 사용하는 곳이 증가 하고 있다.

애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원칙적으로 저장소에 반영해야 한다.

애그리거트에서 두 개의 객체를 변경했는데 저장소에 한 객체에 대한 변경만 변경되면 데이터 일관성이 깨지므로 문제가 된다.

RDBMS를 이용해서 리포지터리를 구현하면 트랜잭션을 이용해서 애그리거트의 변경이 저장소에 반영되는 것을 보장할 수 있다.

몽고 DB를 사용한다면 한 개 애그리거트를 한 개 문서에 저장함으로써 한 애그리거트의 변경을 손실 없이 저장소에 반영할 수 있다.

ID를 이용한 애그리거트 참조

한 객체가 다른 객체를 참조하는 것처럼 애그리거트도 다른 애그리거트를 참조한다.

애그리거트의 관리 주체가 애그리거트 루트 이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 애그리거트의 루트를 참조하는 것과 같다.

order.getOrderer().getMember().getId()

JPA를 사용하면 @ManayToOne, @OneToOne과 같은 애노테이션을 이용해서  연관된 객체를 로딩하는 기능을 제공하고 있으므로 필드를 이용해서 다른 애그리거트를 쉽게 참조할 수 있다.

ORM 기술 덕에 애그리거트 루트에 대한 참조를 쉽게 구현할 수 있고, 필드 (또는 get 메서드)를 이용한 애그리거트 참조를 사용하면 다른 애그리거트의 데이터를 객체탐색을 통해 조회할 수 있다.

필드를 이용한 애그리거트 참조는 문제가 있다.

1) 편한 탐색 오용

2) 성능에 대한 고민

3) 확장 어려움

1) 한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으므로 다른 애그리거트의 상태를 쉽게 변경할 수 있다.

order.getCustomer().changeAddress(newShippingInfo.getAddress());

2) JPA로 사용할 경우 참조한 객체를 지연(lazy) 로딩과 즉시(eager)로딩의 두가지 방식으로 로딩할 수 있다.

두 로딩 방식중 무엇을 사용할지 여부는 애그리거트의 어떤 기능을 사용하느냐에 따라 달라진다.

단순히 연관된 객체의 데이터를 함께 화면에 보여주어야 하면 즉시 로딩이 조회 성능이 유리하지만, 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할  필요가 없으므로 지연 로딩이 유리하다.

이런 다양한 경우의 수를 고려해서 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다.

3) 초기에는 단일 서버에 단일 RDBMS로 서비스를 제공하는것이 가능하다. 문제는 사용자가 몰리기 시작하면서 발생한다.

사용자가 늘고 트래픽이 증가하면 자연스럽게 부하를 분산하기 위해ㅓ 하위 도메인별로 시스템을 분리하기 시작한다.

이 과정에서 하위 도메인마다 서로 다른 DBMS를 사용할 가능성이 높아진다.

하위 도메인마다 다른 종류의 데이터 자장소를 사용하기도 한다.

도메인은 마리아DB를 사용하고 다른 하위 도메인은 몽고DB를 사용하는 식으로 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.

3가지 문제를 완화할 때 사용할 수 있는 것은 ID를 이용해서 다른 애그리거트를 참조하는 것이다.

ID를 이용한 참조는 DB 테이블에서의 외래키를 사용해서 참조하는 것과 비슷하게 다른 애그리거트를 참조할 때 ID 참조를 사용한다

단 애그리거트 내의 엔티티를 참조할 때는 객체 레퍼런스로 참조한다.

ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.

이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.

애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과가 있다.

구현 복잡도도 낮아진다.

다른 애그리거트를 직접 참조하지 않으므로 애그리거트간의 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다. 참조 하는 애그리거트가 필요하면 응용 서비스에서 아이디를 이용해서 로딩하면된다.

public class ChangeOrderService { @Transactional public void chanageShippingInfo(Order Id id, ShippingInfo newShippingInfo, boolean useNewShippingAddrAsMemberAddr) { Order order = orderRepository.findById(id); if(order == null) throw new OrderNotFoundException(); order.shipTo(newShippingInfo); if(useNewShippingAddrAsMemberAddr) { // ID를 이용해서 참조하는 애그리거트를 구한다 Customer customer = customerRepository.findById(orderer.getOrderer().getCustomerId()); customer.changeAddress(newShippingInfo.getAddress()); } } }

응용 서비스에서 필요한 애그리거트를 로딩하므로 애그리거트 수준에서 지연 로딩을 하는 것과 동일한 결과를 만든다.

ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지 할수 있다.

외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경 할 수 없는 것이다.

애그리거트별로 다른 구현 기술을 사용하는 것도 가능해진다.

중요한 데이터인 주문 애그리거트는 RDBMS에 저장하고 조회 성능이 중요한 상품 애그리거트는  NoSQL에 저장 할 수 있다.

또한 각 도메인 별로 프로세스로 서비스하도록 구현 할수도 있다.

ID를 이용한 참조와 조회 성능

다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽어야 할때 조회 속도가 문제가 될수 있다.

주문목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야하는데, 이를 처리할 때 각 주문마다 상품과 회원 애그리거트를 읽어온다고 할 때 한 DBMS에 데이터가 있다면 조인을 이용해서 한 번에 모든 데이터를 가져올 수 있음에도 불구하고 주문마다 상품 정보를 읽어온느 쿼리를 실행하게 된다.

Customer customer = customerRepository.findById(ordererId);  List<Order> orders = orderRepository.findByOrderer(ordererId);  List<OrderView> dtos = orderer.stream()   .map(order ->{   ProductId prodId = order.getOrderLines().get(0).getProductId();   //각 주문마다 첫 번째 주문 상품 정보 로딩을 위한 쿼리 실행   Product product = productRepositroy.findById(procId);   return new OrderView(order, customer, product);   }).collect(toList());

주문 개수 10개면 주문을 읽어오기 위한 1번의 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행한다.

조회 대상이 N개일 때 N개를 읽어오는 한번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다 해서 이를 N+1조회 문제라고 부른다.

ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는데 지연 로딩과 관련된 대표적인 문제가 N+1 조회문제이다.

N+1 조회 문제는 전체 조회속도가 느려지는 원인된다

이를 발생하지 않을려면 조인을 사용해야된다.

조인을 사용하는 가장 쉬운 방법은 ID 참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 사용하도록 매핑 설정을 바꾸는 것이다.

하지만 이 방식은 애그리거트 간 참조를 ID참조 방식에서 객체 참조 방식으로 다시 되돌리는 것이다.

ID참조방식을 사용하면서 N+1 조회와 같은 문제를 해결하기 위해 조인 쿼리를 사용한다.

@Repostory  public clas JpaOrderViewDao implements OrderViewDao {   @PersistenceContext   private EntityManager em;   @Override   public List<OrderView> selectByOrderer(String ordererId) {   String selectQuery =   "select new com.myshop.order.application.dto.OrderView(o, m, p) " +   "from Order o join o.orderLines ol, Member m, Product p "+   "where o.orderer.memberId.id = :ordererId " +   "and o.orderer.memberId = m.id " +   "and index(ol) = 0 " +   "and ol.productId = p.id " +   "order by o.number.number desc";   TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);   query.setParameter("ordererId", ordererId);   return query.getResultList();'   }  }

데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 세타 조인을 이용해서 한 번의 쿼리로 필요한 데이터를 로딩하면된다.

JPQL를 사용하는데, 이 JPQL은 Order 애그리거트와 Member 애그리거트, 그리고 Product 애그리거트를 세타 조인으로 한번의 쿼리로 로딩한다. 즉시 로딩이나 지연로딩과 같은 로딩 전략을 고민할 필요 없이 조회 화면에 필요한 애그리거트 데이터를 한번의 쿼리로 로딩할 수 있다.

쿼리가 복잡하거나 SQL에 특화된 기능을 사용해야 한다면 조회를 위한 부분만 MyBatis와 같은 기술을 이용해서 실행할 수 있다.

애그리거트마다 서로 다른 저장소를 사용하는 경우에는 한 번의 쿼리로 관련 애그리거트를 조회 할 수 없다.

이런 경우 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.

코드의 복잡해지는 단점이 있지만 시스템의 처리량을 높일 수 있다는 장점이 있다.

특히 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생할 경우 캐시나 조회 전용 저장소는 필수로 선택해야하는 기법이다.

애그리거트 간 집합 연관

애그리거트 간의 1:N과 M:N 연관

카테고리와  상품은 1:N 관계

상품과 카테고리는 N:1 관계

애그리거트 간 1:N 관계는 set과 같은 컬렉션을 이용해서 표현할수 있다.

public class Category { private Set<Product> products; // 다른 애그리거트에 대한 1:N 연관 }

개념적으로 존재하는 애그리거트 간의 1:N 연관을 실제 구현에 반영하는 것이 요구사항을 총족하는 것과 상관없는 경우가 있다.

특정 카테고리에 있는 상품 목록을 보여주는 요구사항일경우 보통 목록 관련 요구사항은 한번에 전체 상품을 보여주기보다 페이징을 이용해서 제품을 나눠서 보여준다.

이 기능을 카테고리 입장에서 1-N 연관을 이용해서 구현한다.

public class Category { private Set<Product> porducts; public List<Product> getProducts(int page, int size) { List<Product> sortedProducts = sortById(products); return sortedProducts.subList((page -1) * size, page * size ); } }

DBMS와 연동해서 구현하면 Category에 속한 모든 Product를 조회하게 된다.

Product 개수가 수백에서 수만개 정도로 많다면 이 코드를 실행할 때 마다 실행 속도가 급격히 느려져 성능에 심각한 문제를 일으킨다.

개념적으로는 애그리거트 간 1:N 연관이 있더라면 이런 성능상의 문제 때문에 애그리거트 간의 1:N 연관을 실제 구현에 반영하는 경우는 드물다.

카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카테고리를 N:1로 연관지어 구하면된다.

이를 구현 모델에 반영하면 Product에 Category로의 연관을 추가하고 그 연관을 이용해서 특정 Category에 속한 Product 목록을 구하면된다.

public class Product { private CategoryId category; }

카테고리에 속한 상품 목록을 제공하는 응용 서비스

public class ProductListService { public Page<Product> getProductOfCategory(Long categoryId, int page, int size) { Category category  = categoryRepository.findById(categoryId); checkCategory(category); List<Product> products = productRepository.findByCategoryId(category.getId(), page, size); int totalCount = productRepository.countByCategoryId(category.getId()); return new Page(page, size, totalCount, products); } }

M:N 연관은 개념적으로 양족 애그리거트에 컬렉션으로 연관을 만든다.

상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M:N 연관을 맺는다.

앞서 1:N 연관처럼 M:N 연관도 실제 요구사항을 고려해서  M:N 연관을 구현에 포함시킬지 여부를 결정해야 한다.

보통 특정 카테고리에 속한 상품 목록을 보여줄 때 목록 화면에서 각 상품이 속한 모든 카테고리를 상품정보에 표시하지 않는다.

제품이 속한 모든 카테고리가 필요한 화면은 상품 상세 화면이다.

이 요구사항을 고려할 때 카테고리에서 상품으로의 집합 연관은 필요하지 않다.

상품에서 카테고리로의 집합 연관만 존재하면된다.

개념적으로 상품과 카테고리의 양방향 M:N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M:N 연관만 적용하면 되는 것이다.

RDBMS를 이용해서 M:N 연관를 구현하려면 조인 테이블을 사용한다.

PRODUCT		PRODUCT_CATEGORY		CATEGORY
PRODUCT_ID	-|-----o<	PRODUCT_ID	>o-----|-	CATEGORY_ID
		CATEGORY_ID

                   

JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M:N 단방향 연관을 구현할 수 있다.

@Entity @Table(name = "product") public class Product {     @EmbeddedId     private ProductId id;     @ElementCollection     @CollectionTable(name = "product_category", joinColumns = @JoinColumns(name = "product_id"))     private Set<CategoryId> categoryIds; }

카테고리ID 목록을 보관하기 위해 밸류 타입에 대한 컬렉션 매핑을 이용했다.

이 매핑을 사용하면 JPQL의 member of 연산자를 이용해서 특정 Category에 속한 Product 목록을 구하는 기능을 구현할 수 있다.

@Repository public class JpaProductRepository implements ProductRepository {   @PersistenceContext   private EntityManager entityManager;   @Override   public List<Product> findByCategoryId(CategoryId categoryId, int page, int size) {     TypedQuery<Product> query = entityManger.createQuery(       "select p from Product p " +       "where :catId member of p.categoryIds order by p.id.id desc",       Product.class);       query.setParameter("catId", categoryId);       query.setFirstResult((page -1 ) * size);       query.setMaxResult(size);       return query.getResultList();   } }

:catId member of p.categroyIds 는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지 여부를 검사하기 위한 검색 조건이다.

응용 서비스는 이 기능을 사용해서 지정한 카테고리에 속한 Prodcut 목록을 구할 수 있다.

애그리거트를 팩토리로 사용하기

온라인 쇼핑몰에서 고객이 여려차례 신고를 해서 특정 상점이 더 이상 물건을 등록하지 못하도록 차단한 상태라고 하자

상품 등록 기능을 구현한 응용 서비스는 상점계정이 차단 상태가 아닌 경우에만 상품을 생성하도록 구현할 수 있을 것이다.

public class RegisterProductService {     public ProductId registerNewProduct(NewProductRequest req) {       Store account = accountRepository.findStoreById(req.getStoreId());       checkNull(account);       if(account.isBlocked()) {         throw new StoreBlockedException();       }       ProductId id = productRepository.nextId();       Product product = new Product(id, account.getId(), ...);       ProductRepository.save(product);       return id;     } }

Product를 생성 가능하지 판단하는 코드와 Product를 생성하는 코드가 분리되어 있다.

코드가 나빠 보이지는 않지만 중요한 도메인 로직 처리가 응용 서비스에 노출 되었다.

Store가 Product를 생성할 수 있는지 여부를 판단하고 Product를 생성하는 것은 논리적으로 하나의 도메인 기능인데 이 도메인 기능을 응용 서비스에서 구현하고 있는 것이다.

이 도메인 기능을 넣기 위한 별도의 도메인 서비스나 팩토리 클래스를 만들수도 있지만 이 기능을 구현하기에 더 좋은 장소는 Store 애그리거트이다.

Product를 생성하는 기능을 Store 애그리거트로 옮겨보자

public class Store extends Member {   public Product createProduct(ProductId newProductId, ... ) {     if(isBlocked()) throw new StoreBlockedException();     return new Produect(newProductId, getId(), ...);   } }

Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다.

팩토리 역할을 하면서도 중요한 도메인 로직을 구현하고 있다.

팩토리 기능을 구현했으므로 이제 응용 서비스는 팩토리 기능을 이용해서 Product를 생서하면 된다.

public class RegisterProductService {   public ProductId registerNewProduct(NewProductRequest req) {     Store account = accountRepository.findStoreById(req.getStoreId());     checkNull(account);     ProductId id = productRepository.nextId();     Product product = account.createProduct(id, ...);     productRepository.save(product);     return id;   } }

차이점은 응용 서비스에서 더 이상 Store의 상태를 확인하지 않는다.

Store가 Product를 생성할 수 있는지 여부를 확인하는 도메인 로직은 Store에서 구현하고 있다.

이제 Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.

도메인의 응집도도 높아졌다.

이게 바로 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점이다.

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해보자

Product의 경우 제품을 생성한 Store의 식별자를 필요로 한다.

즉 Store의 데이터를 이용해서 Product를 생성한다.

게다가 Product를 생성 할 수 있는 조건을 판단할 때 Store의 상태를 이용한다.

따라서 Store에 Product를 생성하는 팩토리 메서드를 추가하면 Product를 생서할 떄 필요한 데이터의 일부를 직접 제공하면서 동시에 중요한 도메인 로직을 함께 구현할 수 있게 된다.

DDD START! 도메인주도설꼐구현과 핵심개념 익히기 저자-최범균