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
- Storm
- Angular2
- apache storm
- 인텔리J
- 제주
- Hbase
- Gradle
- elastic search
- Spring
- hibernate
- 도메인주도설계
- hadoop
- Spring Batch
- spark
- Spring Boot
- intellij
- Clean Code
- hdfs
- DDD
- elasticsearch
- Linux
- design pattern
- 엘라스틱서치
- 스프링 배치
- scala
- Spring XD
- docker
- nginx
- Java
- SBT
Archives
- Today
- Total
목록specification (1)
욱'S 노트
DDD - Specification
모든 종류의 어플리케이션에는 규칙을 검사하는 Boolean 테스트 메서드가 있다. 규칙이 단순하다면 invoice.isOverdue와 같이 규칙을 검사하면 된다. 그러나 종종 업무규칙이 엔티티나 VO가 맡고 있는 책임에 맞지 않고 규칙의 다양성과 조합이 도메인 객체의 기본 의미를 압도할 때가 있다. 만약 규칙을 도메인 계층에서 분리를 한다면 예를 들어 응용계층으로 내린다면 상황이 더 악화된다. Specification은 다른 객체에 대한 제약조건을 기술하며, 제약조건은 존재할 수도 존재하지 않을수도 있다. 특정한 목적을 위해 술어와 유사한 명시적인 VO가 바로 SPECIFICATION이다. public class RouteSpecification extends AbstractSpecification im..
Methdology/Domain Driven Design
2016. 1. 27. 17:44