DDD Start! - 2장 아키텍처 개요
Download as PPTX, PDF0 likes1,065 views
아꿈사 스터디 2016/08/20 발표 DDD Start! 도서 2장 아키텍처 개요
DDD Start! - 2장 아키텍처 개요
- 1. 2. 아키텍처 DDD START! 아꿈사 정민철
- 2. 텍스트 네개의 영역 ▸표현: 사용자의 요청을 받아 응용 영역에 전달, 처리결과를 다 시 사용자에게 보여줌 ▸응용: 시스템이 사용자에게 제공해야 할 기능 구현 ▸도메인: 도메인의 핵심 로직을 구현한 도메인 모델 구현 ▸인프라스트럭쳐: 구현 기술에 대한것을 다룸 ▸표현, 응용, 도메인영역 에서는 인프라스트럭쳐에서 제공하는 기능을 사용해 필요한 로직 개발
- 4. 텍스트 계층구조 아키텍처 ▸상위 계층에서 하위 계층에 의존, 반대는 의존하지 않음 ▸구현의 편리함을 위해 계층 구조를 유연하게 적용 표현 응용 도메인 인프라스트럭쳐
- 5. 텍스트 인프라스트럭처 의존의 문제점 ▸직접 사용 시 다른 계층이 상세한 구현 기술을 다룬 인프라스 트럭처 계층에 종속됨 ▸테스트하기 어려워짐 ▸구현 방식을 변경하기 어려워짐 => 기능 확장의 어려움
- 6. 텍스트
- 7. 텍스트
- 8. 텍스트 DIP - (DEPENDENCY INVERSION PRINCIPLE) ▸고차원의 모듈은 저차원의 모듈에 의존하면 안된다. 이 두 모 듈 모두 다른 추상화된 것에 의존 해야 한다. ▸고수준 모듈은 고수준 모듈의 인터페이스에 의존 ▸추상화 된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것 이 추상화된 것에 의존해야 한다. ▸저수준 모듈은 고수준 모듈의 인터페이스 구현
- 9. 텍스트 고수준 저수준
- 10. 텍스트
- 11. 텍스트
- 12. 텍스트 DIP 주의사항 ▸하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도 출한다.
- 13. 텍스트 DIP를 이용한 테스트 ▸실제 구현 클래스가 없어도 테스트 가능 ▸실제 사용할 저수준 구현 객체는 의존성 주입을 이용해 전 달받음 ▸DIP를 적용해 고수준 모듈이 저수준 모듈에 의존하지 않도록 했기 때문
- 14. 텍스트
- 15. 텍스트 DIP와 아키텍처 ▸아키텍처에 DIP를 적용하면 인프라스트럭처 영역이 응용 영 역과 도메인 영역에 의존(상속) 하는 구조가 됨 ▸응용 영역과 도메인 영역에 영향을 최소화 하면서 구현체를 변경하거나 추가할 수 있음
- 16. 텍스트
- 17. 텍스트 도메인 영역의 주요 구성요소 - 1 ▸엔티티 (ENTITY) (e.g. Order, Member, Product …) ▸고유 식별자를 갖는 객체, 자신만의 라이프사이클을 가짐 ▸도메인의 고유한 개념 표현 ▸도메인 모델의 데이터 및 해당 데이터 관련 기능 제공 ▸벨류 (VALUE) (e.g. Address, Money …) ▸고유 식별자를 갖지않는 객체, 개념적으로 하나의 속성을 표현 ▸엔티티 및 다른 벨류의 속성으로 사용
- 18. 텍스트 도메인 영역의 주요 구성요소 - 2 ▸애그리거트 (AGGERGATE) (e.g. 주문 애그리거트 = Order + OrderLine + Orderer) ▸관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것 ▸리포지터리 (REPOSITORY) (e.g. Order table on DBMS) ▸도메인 모델의 영속성을 처리 ▸도메인 서비스 (DOMAIN SERVICE) (e.g. 할인금액 계산) ▸특정 엔티티에 속하지 않은 도메인 로직 제공
- 19. 텍스트 엔티티와 벨류 ▸도메인 모델의 엔티티와 RDBMS의 엔티티는 같지않음 ▸도메인 모델 엔티티: 데이터 + 도메인 기능 ▸두개 이상의 데이터가 개념적으로 하나인 경우 벨류타입으로 표 현 ▸RDBMS의 경우 벨류타입으로 제대로 표현하기 어려움 ▸개념이 드러나지 않고 개별 데이터만 드러나기 때문 ▸벨류는 불변타입으로 구현하는것을 권장 ▸앤티티의 벨류타입 변경 시 객체를 완전히 교체하기 때문
- 20. 텍스트
- 21. 텍스트 애그리거트 ▸관련 객체를 하나로 묶은 군집 ▸점점 복잡해지는 도메인 모델을 개별 객체가 아닌 관련 객체 를 묶어 군집단위로 바라볼 수 있게 해줌 ▸루트 엔티티: 군집에 속한 객체를 관리 ▸엔티티와 벨류 객체를 이용해 애그리거트가 구현해야 할 기 능 제공 ▸애그리거트 사용 객체는 애그리거트 루트를 통해 간접적으 로 애그리거트 내의 엔티티와 벨류 객체에 접근 => 애그리 거트 단위로 캡슐화
- 22. 텍스트
- 23. 텍스트
- 24. 텍스트 리포지터리 ▸물리적인 저장소(RDBMS, NoSQL, 로컬파일 등)에 도메인 객 체 보관 구현을 위한 도메인 모델 ▸애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능 정 의 ▸응용 서비스와 리포지터리의 관계 ▸DI 방식을 사용해 실제 리포지터리 구현 객체에 접근 ▸필요한 도메인 객체를 구하거나 저장할 때 리포지터리 사 용 ▸트랜잭션 관리/처리 시 리포지터리 구현 기술에 영향을 받 음
- 25. 텍스트
- 26. 텍스트 요청 처리 흐름
- 27. 텍스트 인프라스트럭처 개요 ▸표현, 응용, 도메인 영역 지원 ▸다른 영역에서 필요한 프레임워크, 구현 기술, 보조 기능 지원 ▸다른 영역에서 정의한 인터페이스를 인프라스트럭처 영역에서 구현 ▸시스템을 더 유연하고 테스트하기 쉽게 만들어줌 ▸다만 구현의 편리함과 균형을 생각해 DIP V.S. 기술의존 결정 필요 ▸표현 영역은 항상 인프라스트럭쳐 영역과 쌍을 이룸 ▸e.g. 스프링 MVC를 인프라스트럭쳐로 사용 시 이에 맞게 표현 영역도 사용해야 함
- 28. 텍스트
- 29. 텍스트 모듈 구성 ▸아키텍처의 각 영역은 별도 패키지에 위치 ▸영역별로 모듈이 위치할 패키지 구성 ▸도메인이 크면 하위 도메인으로 나누고 각 하위 도메인 별 패 키지 구성 ▸도메인 모듈은 속한 에그리거트를 기준으로 다시 패키지 구성 ▸각 애그리커트와 모델과 리포지터리는 같은 패키지에 위치 ▸한 패키지에 너무 많은 타입이 몰리지 않도록 구성
- 30. 텍스트
- 31. 텍스트
- 32. 텍스트