ddd start! - 2장 아키텍처 개요

32
2. 아아아아 아아 DDD START! 아아아 아아아

Upload: minchul-jung

Post on 13-Jan-2017

119 views

Category:

Software


2 download

TRANSCRIPT

2. 아키텍처 개요DDD START! 아꿈사 정민철

텍스트

네개의 영역▸ 표현 : 사용자의 요청을 받아 응용 영역에 전달 , 처리결과를 다시 사용자에게 보여줌▸ 응용 : 시스템이 사용자에게 제공해야 할 기능 구현▸ 도메인 : 도메인의 핵심 로직을 구현한 도메인 모델 구현▸ 인프라스트럭쳐 : 구현 기술에 대한것을 다룸▸ 표현 , 응용 , 도메인영역 에서는 인프라스트럭쳐에서 제공하는 기능을 사용해 필요한 로직 개발

텍스트

계층구조 아키텍처▸ 상위 계층에서 하위 계층에 의존 , 반대는 의존하지 않음▸ 구현의 편리함을 위해 계층 구조를 유연하게 적용

표현응용

도메인

인프라스트럭쳐

텍스트

인프라스트럭처 의존의 문제점▸ 직접 사용 시 다른 계층이 상세한 구현 기술을 다룬 인프라스트럭처 계층에 종속됨

▸ 테스트하기 어려워짐▸ 구현 방식을 변경하기 어려워짐 => 기능 확장의 어려움

텍스트

텍스트

텍스트

DIP - (DEPENDENCY INVERSION PRINCIPLE)▸ 고차원의 모듈은 저차원의 모듈에 의존하면 안된다 . 이 두 모듈 모두 다른 추상화된 것에 의존 해야 한다 .

▸ 고수준 모듈은 고수준 모듈의 인터페이스에 의존▸ 추상화 된 것은 구체적인 것에 의존하면 안 된다 . 구체적인 것이 추상화된 것에 의존해야 한다 .

▸ 저수준 모듈은 고수준 모듈의 인터페이스 구현

텍스트

고수준

저수준

텍스트

텍스트

텍스트

DIP 주의사항▸ 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출한다 .

텍스트

DIP 를 이용한 테스트▸ 실제 구현 클래스가 없어도 테스트 가능

▸ 실제 사용할 저수준 구현 객체는 의존성 주입을 이용해 전달받음▸ DIP 를 적용해 고수준 모듈이 저수준 모듈에 의존하지 않도록 했기 때문

텍스트

텍스트

DIP 와 아키텍처▸ 아키텍처에 DIP 를 적용하면 인프라스트럭처 영역이 응용 영역과 도메인 영역에 의존 ( 상속 ) 하는 구조가 됨▸ 응용 영역과 도메인 영역에 영향을 최소화 하면서 구현체를 변경하거나 추가할 수 있음

텍스트

텍스트

도메인 영역의 주요 구성요소 - 1

▸ 엔티티 (ENTITY) (e.g. Order, Member, Product …)▸ 고유 식별자를 갖는 객체 , 자신만의 라이프사이클을 가짐▸ 도메인의 고유한 개념 표현▸ 도메인 모델의 데이터 및 해당 데이터 관련 기능 제공

▸ 벨류 (VALUE) (e.g. Address, Money …)▸ 고유 식별자를 갖지않는 객체 , 개념적으로 하나의 속성을 표현▸ 엔티티 및 다른 벨류의 속성으로 사용

텍스트

도메인 영역의 주요 구성요소 - 2

▸ 애그리거트 (AGGERGATE) (e.g. 주문 애그리거트 = Order + OrderLine + Orderer)▸ 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것

▸ 리포지터리 (REPOSITORY) (e.g. Order table on DBMS)▸ 도메인 모델의 영속성을 처리

▸ 도메인 서비스 (DOMAIN SERVICE) (e.g. 할인금액 계산 )▸ 특정 엔티티에 속하지 않은 도메인 로직 제공

텍스트

엔티티와 벨류▸ 도메인 모델의 엔티티와 RDBMS 의 엔티티는 같지않음

▸ 도메인 모델 엔티티 : 데이터 + 도메인 기능▸ 두개 이상의 데이터가 개념적으로 하나인 경우 벨류타입으로 표현▸ RDBMS 의 경우 벨류타입으로 제대로 표현하기 어려움

▸ 개념이 드러나지 않고 개별 데이터만 드러나기 때문▸ 벨류는 불변타입으로 구현하는것을 권장

▸ 앤티티의 벨류타입 변경 시 객체를 완전히 교체하기 때문

텍스트

텍스트

애그리거트▸ 관련 객체를 하나로 묶은 군집

▸ 점점 복잡해지는 도메인 모델을 개별 객체가 아닌 관련 객체를 묶어 군집단위로 바라볼 수 있게 해줌▸ 루트 엔티티 : 군집에 속한 객체를 관리

▸ 엔티티와 벨류 객체를 이용해 애그리거트가 구현해야 할 기능 제공▸ 애그리거트 사용 객체는 애그리거트 루트를 통해 간접적으로 애그리거트 내의 엔티티와 벨류 객체에 접근 => 애그리거트 단위로 캡슐화

텍스트

텍스트

텍스트

리포지터리▸ 물리적인 저장소 (RDBMS, NoSQL, 로컬파일 등 ) 에 도메인 객체 보관 구현을 위한 도메인 모델▸ 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능 정의▸ 응용 서비스와 리포지터리의 관계

▸ DI 방식을 사용해 실제 리포지터리 구현 객체에 접근▸ 필요한 도메인 객체를 구하거나 저장할 때 리포지터리 사용▸ 트랜잭션 관리 / 처리 시 리포지터리 구현 기술에 영향을 받음

텍스트

텍스트

요청 처리 흐름

텍스트

인프라스트럭처 개요▸ 표현 , 응용 , 도메인 영역 지원▸ 다른 영역에서 필요한 프레임워크 , 구현 기술 , 보조 기능 지원▸ 다른 영역에서 정의한 인터페이스를 인프라스트럭처 영역에서 구현

▸ 시스템을 더 유연하고 테스트하기 쉽게 만들어줌▸ 다만 구현의 편리함과 균형을 생각해 DIP V.S. 기술의존 결정 필요▸ 표현 영역은 항상 인프라스트럭쳐 영역과 쌍을 이룸

▸ e.g. 스프링 MVC 를 인프라스트럭쳐로 사용 시 이에 맞게 표현 영역도 사용해야 함

텍스트

텍스트

모듈 구성▸ 아키텍처의 각 영역은 별도 패키지에 위치▸ 영역별로 모듈이 위치할 패키지 구성▸ 도메인이 크면 하위 도메인으로 나누고 각 하위 도메인 별 패키지 구성▸ 도메인 모듈은 속한 에그리거트를 기준으로 다시 패키지 구성▸ 각 애그리커트와 모델과 리포지터리는 같은 패키지에 위치▸ 한 패키지에 너무 많은 타입이 몰리지 않도록 구성

텍스트

텍스트

텍스트