Domain Driven Design
-
DDD - ORM과 투명한 영속성 10부 11부JAVA/DDD 2021. 1. 24. 08:10
DDD 이터니티 조용호 님의 블로그를 보고 다시 한번 공부하기 위해서 정리하게 되었습니다! 애초에 아키텍처를 잡을 때 영속성을 고려했어야 했는데 아키텍처의 중요성을 뼈저리게 느끼게 되는 순간이다. 뭔가 망가지지 않았을까? 이럴 때 의지할 수 있는 건 단 하나밖에 없다. 회귀 테스트를 믿으라. 테스트를 실행하기 전에 한가지 더 알려 둘 것이 있다. 가능하면 단위 테스트는 데이터베이스에 의존하지 않은 채로 실행할 수 있어야 한다. 즉, 데이터베이스가 가동되지 않아도 각 클래스만을 고립시켜 테스트할 수 있도록 테스트 케이스를 작성해야 한다. 정확하게 말하면 데이터베이스를 포함시키는 테스트는 단위 테스트가 아니라 통합 테스트이다. 데이터베이스와 연계해야 하는 통합 테스트에서 가장 어려운 문제는 테스트 데이터를 ..
-
DDD - ORM과 투명한 영속성 8부 9부JAVA/DDD 2021. 1. 24. 07:43
OrderLineItem에도 Long 타입의 IDENTITY FILED를 추가한다. @Cofigurable Annotation이 계속 사용되고 있음에 주목하자. @Cofigurable Annotation은 Spring 컨테이너 외부에서 생성되는 객체에 Spring 컨테이너에서 선언된 빈을 의존 삽입하기 위해 사용된다. 여기에서는 Hibernate가 생성하는 OrderLineItem 객체에 ProductRepository 타입의 빈을 의존 삽입하기 위해 사용되고 있다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 @Configurable(value="orderLineItem",preConstruction=true) public class OrderL..
-
DDD. ORM과 투명한 영속성 2부JAVA/DDD 2021. 1. 23. 13:24
REFERENCE OBJECT의 별칭(aliasing) - ENTITY REFERENCE OBJECT는 시스템 내에 유일하게 존재하고 상태를 추적할 수 있는 도메인 객체를 의미한다. REFERENCE OBJECT는 유일성 및 추적성을 만족시키기 위해 식별자(identity)를 가지며 동일한 객체를 다른 이름으로 참조할 수 있도록 별칭(aliasing)을 허용한다. 별칭은 여러가지 골치 아픈 문제를 야기하지만 그와 동시에 시스템의 모든 부분이 REFERENCE OBJECT의 상태를 공유할 수 있도록 함으로써 도메인의 무결성을 유지하도록 한다. REFERENCE OBJECT의 동일함(identical)을 테스트하기 위해 ‘==’ 연산자를 사용하여 식별자를 비교할 수 있다. ‘==’ 연산자는 객체 생성 시에 ..
-
DDD - Dependency Injection과 AOP 4부 5부JAVA/DDD 2021. 1. 22. 22:17
우선 ProductRepository를 리팩토링하자. 구체적인 클래스에서 인터페이스를 추출하는 EXTRACT INTERFACE를 적용하자. 인터페이스 명은 ProductRepository로 하고 구현 클래스 명은 CollectionProductRepository로 하자. 1 2 3 4 5 6 7 8 9 10 ProductRepository.java public interface ProductRepository { public void save(Product product); public Product find(String productName); } Colored by Color Scripter cs 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 CollectionProduc..
-
DDD - Dependency Injection과 AOP 3부JAVA/DDD 2021. 1. 22. 22:03
영속성(Persistence)과 REPOSITORY REPOSITORY는 도메인 객체 생성 이후의 생명주기를 책임진다. 도메인 객체가 생성되고 상태가 초기화된 후에는 REPOSITORY에게 넘겨진다. REPOSITORY는 객체를 넘겨받아 내부 저장소에 보관하고 요청이 있을 경우 객체를 조회하여 반환하거나 삭제한다. 클라이언트 입장에서 REPOSITORY는 커다란 메모리에 도메인 객체들을 담고 있는 객체 풀(object pool)과 같다. 클라이언트는 생성된 객체를 REPOSITORY에게 전달하고 객체가 필요한 경우 REPOSITORY에게 객체 풀 안의 어딘가에 잠자고 있는 도메인 객체를 찾아 달라고 요청한다. REPOSITORY의 기능을 메모리 컬렉션에 대한 오퍼레이션으로 바라보는 것은 도메인 모델을 단..
-
DDD - Dependency Injection과 AOP 2부JAVA/DDD 2021. 1. 22. 21:41
객체 그리고 영속성(Persistence) 모든 객체는 생성자가 호출되는 시점에 생성된다. VALUE OBJECT의 수명은 짧다. 생성된 후 잠시 다른 REFERENCE OBJECT 또는 VALUE OBJECT에 의해 사용되다가 다른 VALUE OBJECT로 대체된다. 갈 길을 잃은 VALUE OBJECT는 가비지 컬렉터에게 넘겨진 후 조용히 생을 마감한다. VALUE OBJECT에 비해 REFERENCE OBJECT의 수명은 상대적으로 길다. REFERENCE OBJECT는 다양한 이벤트에 반응함에 따라 상태가 변한다. 일단 고객 객체가 생성되면 시스템은 고객이 탈퇴할 때까지 고객 객체를 참조하고 추적할 수 있어야 한다. 이를 위해 도메인 모델에 추가되는 PURE FABRICATION이 REPOSITO..
-
AGGREGATE와 REPOSITORY 5부JAVA/DDD 2021. 1. 8. 19:48
ENTRY POINT와 REPOSITORY 주문은 주문 AGGREGATE의 ENTRY POINT이다. 따라서 주문이 필요한 경우 OrderRepository를 통해 해당 주문 객체를 얻을 수 있다. 그럼 특정한 고객에 대한 주문 목록을 얻어야 한다면 어떻게 해야 할까? 쉽게 생각해 볼 수 있는 방법은 CustomerRepository로부터 고객 객체를 얻은 후 연관을 통해 해당하는 Order 객체들에게 접근하는 것이다. 그러나 이 방법은 Order와 Customer 클래스 간에 양방향 연관 관계를 추가한다. 특정 객체에 속하는 다른 객체들을 조회하는 요구사항마다 양방향 연관 관계를 설정한다면 감당하기 어려울 정도로 모델이 복잡해질 것이다. 고객에 해당하는 주문 목록을 조회하는 적절한 방법은 OrderRe..
-
AGGREGATE와 REPOSITORY 1부JAVA/DDD 2020. 12. 28. 15:39
고객(Customer)은 시스템을 사용해서 상품을 주문(Order)한다. 한 번 주문 시 다수의 상품(OrderLineItem)을 구매할 수 있으며 상품에 대한 이름(name), 가격(price)과 같은 기본 정보는 별도의 상품(Product) 클래스에 정의되어 있다. 고객은 고객 등급에 따라 일 회 주문 시 구매 가능한 금액에 제한(limitPrice 프로퍼티)을 받는다. 앞의 도메인 모델에서 Customer 클래스와 Money 클래스를 표기한 방법에 주목하자. 일반적으로 REFERENCE OBJECT는 독립적인 클래스로 표기하는 반면, VALUE OBJECT는 클래스의 속성으로 표기한다. 좋은 모델이란 충분한 정보를 다루면서도 세부 사항에 집착하지 않고 핵심 주제를 효과적으로 전달하는 모델이다. 주문..