Notice
Recent Posts
Recent Comments
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- Gradle
- hadoop
- Angular2
- apache storm
- hdfs
- scala
- Storm
- Spring Boot
- Domain Driven Design
- design pattern
- SBT
- intellij
- 엘라스틱서치
- Hbase
- Java
- Spring
- DDD
- spark
- Spring Batch
- elastic search
- elasticsearch
- hibernate
- Linux
- docker
- nginx
- Clean Code
- Spring XD
- 도메인주도설계
- 제주
- 스프링 배치
Archives
- Today
- Total
욱'S 노트
DDD - Specification 본문
모든 종류의 어플리케이션에는 규칙을 검사하는 Boolean 테스트 메서드가 있다. 규칙이 단순하다면 invoice.isOverdue와 같이 규칙을 검사하면 된다.
그러나 종종 업무규칙이 엔티티나 VO가 맡고 있는 책임에 맞지 않고 규칙의 다양성과 조합이 도메인 객체의 기본 의미를 압도할 때가 있다. 만약 규칙을 도메인 계층에서 분리를 한다면 예를 들어 응용계층으로 내린다면 상황이 더 악화된다.
Specification은 다른 객체에 대한 제약조건을 기술하며, 제약조건은 존재할 수도 존재하지 않을수도 있다. 특정한 목적을 위해 술어와 유사한 명시적인 VO가 바로 SPECIFICATION이다.
public class RouteSpecification extends AbstractSpecification<Itinerary> implements ValueObject<RouteSpecification> {
위는 경로가 만족하는지를 검사하는 Specification 객체이다.
@Override
public boolean isSatisfiedBy(final Itinerary itinerary) {
return itinerary != null &&
origin().sameIdentityAs(itinerary.initialDepartureLocation()) &&
destination().sameIdentityAs(itinerary.finalArrivalLocation()) &&
arrivalDeadline().after(itinerary.finalArrivalDate());
}
위와 같은 형태로 구현된다.
public void assignToRoute(final Itinerary itinerary) {
Validate.notNull(itinerary, "Itinerary is required for assignment");
this.itinerary = itinerary;
// Handling consistency within the Cargo aggregate synchronously
this.delivery = delivery.updateOnRouting(this.routeSpecification, this.itinerary);
}
카고에 새로운 경로가 할당되어 루트를 수정한다면 위와 같은 형태로 전달되어 경로를 검증하게 된다.
'Methdology > Domain Driven Design' 카테고리의 다른 글
DDD - 유연한 설계 (0) | 2016.01.27 |
---|---|
DDD - Aggregate, Factory, Repository (0) | 2016.01.27 |
DDD - 엔티티, VO, 서비스 (0) | 2016.01.27 |
DDD - 도메인의 격리 (0) | 2016.01.27 |
DDD - 모델 주도 설계 (0) | 2016.01.27 |
Comments