도메인 주도 아키텍처
*하위계층으로 갈수록 의존성 높아진다.
Presentation Layer(Controller): 사용자 요청받아 서비스 영역에 전달 및 결과 반환
Application Layer(Service)
- 사용자 요청 처리 위해 repository부터 도메인 객체 가져와서 사용
- 기본 Buiness Logic은 Entity나 VO에 담기는게 좋지만, Application Logic은 Service층에 넣어준다.
- 다른 도메인모델들을 이용하여 어플리케이션 기능 구현
- 로직 직접 수행 보다는 도메인 모델에 로직 수행 준다
- transaction 처리
*transaction: db 상태 변화시키기 위한 일련의 단위
Domain Layer(Entity): 도메인 영역 및 모델
Infra Layer(Repoistory): 도메인 모델 영속성 담당
DDD 특징
- 도메인을 서비스별로 분리!
DDD 장점
- 유연성과 확장성이 높다.
- 데이터중심 접근법이 아닌 순수한 도메인의 모델과 로직에 집중한다.
- s/w entity와 도메인 컨셉트를 일치시킨다.
Domain Layer
https://happy-coding-day.tistory.com/62
Transaction Script
하나의 Transaction을 수행하기 위한 일련의 코드. 도메인 객체(entity)가 entity만 갖고 있고, 하나의 트랜잭션 안에 모든 로직은 포함된형태. 그러므로 Application Logic도 담는다.
절차적 코딩, 시스템에서 data를 어떻게 무엇을 저장할 것인가 초점
단점:
- 유연성, 모듈화, 유지보수, 재사용성
Domain Model Pattern
- Domain을 개념적으로 표현한 것
- Domain Layer을 OOP기업으로 구현하는 패턴
- process와 data를 따로 생각하는 것이 아닌 하나의 덩어리
모델
- Entity, Value
- 데이터와 도메인 기능 제공
Aggregate
- 관련 Entity와 Value Object들을 개념적으로 하나 묶는다.
- 한 Aggregate에 속한 Entity는 다른 Aggregate에 속하지 않는다.
- Aggregate에 속하는 관리하는 Entity를 Aggregate Root라고 한다.
- Aggregate Root는 Aggregate일관성이 깨지지 않도록 한다.
Domain Servie
기본적인 비즈니스 로직은 Entity나 VO에 담는것이 좋지만, 특정 객체의 책임이 애매하면 Domain Service를 사용한다. 여기에는 Application Logic이 없다.
(예) 계좌이체 로직은 계좌 애그리거트의 상태를 변경한다. 결제 금액 로직은 주문 애그리거트의 주문 금액을 계산한다.
이 두 로직은 각각 애그리거트를 변경하고 애그리거트의 값을 계산하는 도메인 로직이다.
도메인 로직이면서 한 애그리거트에 넣기 적합하지 않으므로 이 두 로직은 도메인 서비스로 구현하게 된다.
- 트랜잭션 처리와 같은 로직은 응용 로직이므로 응용 서비스에서 처리해야 한다.
트랜잭션스크립트
서비스 - 도메인서비스, 어플리케이션서비스(usecase 명세서)
어플리케이션서비스 - usecase명세서 순서
[usecase 명세서]
- 사용자 검증
<포스트> -> 도메인로직쪽으로 빼라 - 게시글이 있는지 검증
- 게시글이 유효한지 검증
<포스트> - 대댓글인지 확인
- post state를 완료
- 댓글 저장(repostitory 저장)
