티스토리

bada

검색하기

블로그 홈

bada

devfunny.tistory.com/m

shbada 님의 블로그입니다.

구독자: 35

방명록 방문하기

반응형

주요 글 목록

[Domain Driven Design] 11. 애그리거트 간 집합 연관, 애그리거트의 팩토리 역할 애그리거트 간 집합 연관 애그리거트 간 1:N, N:1 연관에 대해 알아보자. 이 두 연관은 컬렉션(Collection)을 이용한 연관이다. 카테고리와 상품 간의 연관이 대표적이다. 카테고리 입장에서 한 카테고리에 한 개 이상의 상품이 속할 수 있으니 카테고리와 상품은 1:N 관계이다. 한 상품이 한 카테고리에만 속할 수 있다면 상품과 카테고리 관계는 N:1 관계이다. 애그리거트 간 1:N 관계는 Set과 같은 컬렉션을 이용해서 표현할 수 있다. 예를 들어 다음 코드처럼 Category가 연관된 Product를 값으로 갖는 컬렉션을 필드로 정의할 수 있다. public class Category { private Set products; // 다른 애그리거트에 대한 1:N 연관 ... } 개념적으로 존재.. 공감수 2 댓글수 1 2022. 10. 11.
[Domain Driven Design] 10. 리포지토리와 애그리거트, 애그리거트 간의 참조 관계 리포지토리와 애그리거트 애그리거트는 개념상 완전한 한개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. Order와 OrderLine을 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrderLine을 위한 리포지터리를 각각 만들지 않는다. Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지토리만 존재한다. 새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어야 하므로, 리포지터리는 보통 다음의 두 메서드를 기본으로 제공한다. 이 두 메서드 외에 필요한 다양한 조건으로 애그리거트를 검색하는 메서드나 애그리거트를 삭제하는 메서드를.. 공감수 1 댓글수 0 2022. 10. 8.
[Domain Driven Design] 9. 애그리거트 루트 (Aggregate Root) 애그리거트 애그리거트는 여러 객체로 구성된다. 그렇기 때문에 한 객체만 상태가 정상이면 안되고, 애그리거트에 속한 모든 객체가 정상 상태를 가져야 도메인 규칙을 지킬 수 있다. [예시] 주문 애그리거트를 보자. Order 엔티티 - 총 금액 totalAmounts를 갖고있다. OrderLine 밸류 - 개별 구매 상품의 개수인 quantity와 금액인 price를 갖고있다. 구매할 상품의 개수를 변경하면 한 OrderLine의 quantity를 변경하고 더불어 Order의 totalAmounts도 변경해야한다. 그렇지 않으면 다음 도메인 규칙을 어기고 데이터 일관성이 깨진다. 루트 애그리거트 애그리거트에 속한 모든 객체가 일관성 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는.. 공감수 6 댓글수 1 2022. 10. 7.
[Domain Driven Design] 8. 애그리거트 (Aggregate) 애그리거트가 필요한 이유 아래 그림을 보면, 주문이 회원, 상품, 결제와 관련된 것임을 쉽게 알 수 있다. 상위 수준 모델을 개별 객체 단위로 다시 그려보자. 개별 객체 수준에서 모델을 바라보면 상위 수준에서 관계를 파악하기 어렵다. 도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고, 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다. 주요 도메인을 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 상위 수준에서 모델이 어떻게 엮여 있는지 알아야 전체 모델을 망가뜨리지 않으면서 추가 요구사항을 모델에 반영할 수 있는데, 세부적인 모델만 이해한 상태로는 코드를 수정하는 것이 꺼려지기 때문에 코드 변경을 최대한 회피하는 쪽으로 요구사항.. 공감수 1 댓글수 0 2022. 10. 4.
[Domain Driven Design] 7. 응용 서비스, 인프라스트럭처 개요, 모듈 구조 응용 서비스 사용자 입장에서 봤을때 웹 애플리케이션이나 데스크톱 애플리케이션과 같은 소프트웨어는 기능을 제공한다. 사용자가 애플리케이션에 기능 실행을 요청하면 그 요청을 처음 받는 영역은 표현 영역이다. 스프링 MVC를 사용해서 웹 애플리케이션을 구현했다면 컨트롤러가 사용자의 요청을 받아 처리하게 된다. 표현 영역은 사용자가 전송한 데이터 형식이 올바른지 검사하고 문제가 없다면 데이터를 이용해서 응용 서비스에 기능 실행을 위임한다. 이때 표현 영역은 사용자가 전송한 데이터를 응용 서비스가 요구하는 형식으로 변환해서 전달한다. 웹 브라우저를 이용해서 기능 실행을 요청하면 표현 영역에 해당하는 컨트롤러는 과정 1.1에서 HTTP 요청 파라미터를 응용 서비스가 필요로 하는 데이터로 변환해서 응용 서비스를 실행.. 공감수 2 댓글수 2 2022. 9. 25.
[Domain Driven Design] 6. 도메인 영역의 구성요소 (엔티티, 밸류, 애그리거트, 리포지토리) 구성요소 도메인 영역은 도메인의 핵심 모델을 구현한다. 도메인 영역의 모델은 도메인의 주요 개념을 표현하며 핵심 로직을 구현한다. 도메인 영역을 구성하는 요소 요소 설명 엔티티 ENTITY 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다. 밸류 VALUE 고유의 식별자를 갖지 않는 객체로 주요 개념적으로 하나의 값을 표현할때 사용된다. 배송지 주소를 표현하기 위한 주소나 구매 금액을 위한 금액와 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다. 애그리거트 AGGREAGATE 애그리거트는 연관된 엔.. 공감수 0 댓글수 0 2022. 9. 24.
[Domain Driven Design] 5. DIP(Dependency Inversion Principle, 의존 역전 원칙) 인프라스트럭처 의존성 문제점 표현 계층, 응용 계층, 도메인 계층이 상세한 구현 기술을 다루는 인프라스트럭처 계층에 의존성이 존재하는 경우의 문제점 https://devfunny.tistory.com/872 [Domain Driven Design] 4. 계층 구조 아키텍처 (표현, 응용, 도메인, 인프라스트럭처) 네 개의 영역 '표현', '응용', '도메인', '인프라스트럭쳐' 는 아키텍처를 설계할 때 출현하는 전형적인 네가지 영역이다. 표현 영역(또는 UI 영역)은 사용자의 요청을 받아 응용 영역에 전달하고 devfunny.tistory.com 문제 상황 가격 할인 계산을 하려면 고객 정보를 구해야하고, 구한 고객 정보와 주문 정보를 이용해서 룰을 실행해야한다. 여기서 CalculateDiscountS.. 공감수 0 댓글수 0 2022. 9. 18.
[Domain Driven Design] 4. 계층 구조 아키텍처 (표현, 응용, 도메인, 인프라스트럭처) 네 개의 영역 '표현', '응용', '도메인', '인프라스트럭쳐' 는 아키텍처를 설계할 때 출현하는 전형적인 네가지 영역이다. 표현 영역(또는 UI 영역)은 사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 다시 보여주는 역할을 한다. 웹 애플리케이션을 개발할때 많이 사용하는 스프링 MVC 프레임워크가 표현 영역을 위한 기술에 해당한다. 웹 애플리케이션에서 표현 영역의 사용자는 웹 브라우저를 사용하는 사람일 수도 있고, REST API를 호출하는 외부 시스템일 수도 있다. 웹 애플리케이션의 표현 영역은 HTTP 요청을 응용 영역이 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 응용 영역의 응답을 HTTP 응답으로 변환하여 전송한다. 표현 영역을 통해 사용자의 요청을 전달받는 응용 .. 공감수 0 댓글수 0 2022. 9. 18.
[Domain Driven Design] 3. 엔티티와 밸류 엔티티와 밸류 도출한 모델은 크게 엔티티(Entity)와 밸류(Value)로 구분할 수 있다. 앞서 요구사항 분석 과정에서 만든 모델은 엔티티도 존재하고 밸류도 존재한다. 앤티티와 밸류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 이 둘의 차이를 명확하게 이해하는 것은 도메인을 구현하는 데 있어 중요하다. 엔티티 엔티티는 식별자를 가진다. 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 주문에서 배송지 주소가 바뀌거나 상태가 바뀌더라도 주문번호(식별자)가 바뀌지 않는 것처럼 엔티티의 식별자는 바뀌지 않는다. 엔티티를 생성하고 속성을 바꾸고 삭제할 떄까지 식별자는 유지된다. 엔티티의 식별자는 바뀌지 않고 고유하기 때문에 두 엔티티 객체의 식별자가 같으면 두.. 공감수 1 댓글수 0 2022. 9. 18.
[Domain Driven Design] 2. 도메인 모델 도메인 모델 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다. 예시로 '주문 도메인'을 보자. 주문을 하기위해 상품을 몇 개 살지 선택하고 배송지를 입력한다. 선택한 상품 가격을 이용해서 총 지불 금액을 계산하고, 금액 지불을 위한 결제 수단을 선택한다. 주문한 뒤에도 배송 전이면 배송지 주소를 변경하거나 주문을 취소할 수 있다. 위 그림은 객체를 이용한 도메인 모델이다. 도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다. 도메인 모델을 객체로만 모델링할 수 있는 것은 아니다. 상태 다이어그램을 이용해서 주문의 상태 전이를 모델링하고 있다. 이 다이어그램을 보면 상품 준비 .. 공감수 0 댓글수 0 2022. 9. 17.
[Domain Driven Design] 1. 도메인이란? 도메인이란? '온라인 서점'을 예시로 들어보자. 온라인 서점에서 책에 관련된 많은 기능들을 제공한다. 개발자 입장에서 '온라인 서점'은 구현해야 할 소프트웨어의 대상이 된다. 온라인 서점 소프트웨어는 온라인으로 책을 판매하는 데 필요한 상품 조회, 구매, 결제, 배송 추적 등의 기능을 제공해야한다. 이때 '온라인 서점'은 소프트웨어로 해결하고자 하는 문제 영역에 해당한다. 한 도메인은 다시 하위 도메인으로 나눌 수 있다. 온라인 서점'의 하위 도메인 : 카탈로그, 회원, 결제, 배송, 정산 등 각 하위 도메인은 각자의 서비스에 맞는 기능을 제공한다. 카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다. 한 하위 도메인은 다른 하위 도메인과 연.. 공감수 1 댓글수 0 2022. 9. 16.

반응형

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.