화물에서 RouteSpecification을 분리하는 목적은 무엇입니까

Question

ddd 샘플 응용 프로그램을 보면 CargoCargo.java 개체에 RouteSpecification에 대한 별도의 참조가 필요한 이유를 알 수 없습니다. 여행 일정이화물 노선을 만족하거나 수없는 경우

유효성을 검사하는 데 사용되는화물 클래스의 origin, destination and arrivalDeadline 부분을 가지고 모두이 RouteSpecification 클래스를 건너 뛰고 같은 updateDestination 및 satisfiedByItinerary

RouteSpecification 등의 방법을 노출하는 것이 더 간단하지 않을까요 그러나 그러한 작업이 카고 클래스 자체로 처리 될 수없는 이유는 없습니다.이 분리의 요점은 무엇입니까?

public class Cargo implements Entity<Cargo> { 

    ... 
    private Location origin; 
    private Location destination; 
    private Date arrivalDeadline; 
    ... 

Answer 1

문서를 살펴보면 version 1 introduction에 유용한 포인터가 있습니다.

DDD 속도를 높이기 위해 가장 많이 요구되는 기능 중 하나는 실행중인 예제 응용 프로그램입니다. 이를 감안할 때 에릭 에반스 '책

에 사용되는화물의 예에 따라 기능의 간단한 세트 모델에서 시작, 우리는 합리적으로 설계 the blue book의 7 장과 비슷한 동기를 가지고 있다고 가정 할 수 있습니다.

배달 사양은 최소한 대상과 도착 데이터를 포함하는 배달 목표를 정의하지만 더 복잡 할 수 있습니다. 이 클래스는 명세 패턴을 따른다.

이 책임은 Cargo 객체에서 취할 수 있지만 배달 사양의 추상화는 최소한 세 가지 이점을 제공합니다.

1. 배달 지정이없는화물 개체는 배달 목표를 지정하기위한 모든 특성 및 연결의 세부적인 의미를 담당합니다. 이것은 Cardo를 어지럽히고 변경하기가 더 어렵게 만듭니다.

2. 이 추상화를 통해 모델 전체를 설명 할 때 세부 사항을 쉽고 안전하게 지울 수 있습니다. 예를 들어 배달 사양에 캡슐화 된 다른 기준이있을 수 있지만이 세부 수준의 다이어그램에서는 노출을 노출 할 필요가 없습니다. 이 다이어그램은 전달 사양이 있다는 것을 독자에게 알려주고 있으며 그 세부 사항은 생각할 필요가 없습니다 (실제로 나중에 쉽게 변경 될 수 있음).

3. 이 모델은 더 표현력이 있습니다.배달 명세서를 추가하면화물의 정확한 배달 수단이 결정되지 않았지만 배달 사양에 명시된 목표를 달성해야한다는 것이 명시되어 있습니다.

But then why isn't origin a part of RouteSpecification? 

나는 전체 프로젝트의 역사를 통해 파고 사라하지 않은,하지만 내 생각은 Cargo.origin 및 RouteSpecification.origin 실제로 서로 호환되지 않습니다 것입니다. (출발지는 RouteSpecification의 일부이지만 RouteSpecification은 시간이 지남에 따라 변경 될 수 있음). version one javadoc

에서

화물이 새로운 경로가화물 및 새로운 경로가 요청에 대해 지정되는 경우에는 고객의 요구에 따라, 운송 중에 다시 라우팅 할 수 있습니다.

화물이 우발적으로 잘못 운송되어 적절한 인원에게 알려야하며 재 라우팅 절차가 필요합니다.

버전은 하나의 코드화물 (잘못 라우팅과 동일하지 않다)잘못 전달 될 수 있음을 나타낸다.

differentscenarios을주의 깊게 살펴보면 다른 방향으로 잘못 지시하는 것을 볼 수 있습니다. 새로운 버전은 라우트 스펙을 바꾸고 일치하는 여정을 검색하여이를 수행합니다.

Answer 2

완전히 솔루션에서 RouteSpecification 클래스를 리팩토링의 결과를 고려하면, 당신은 origin, destination 및 arrivalDeadline 함께 많은 시간을 건네받을 것으로 보인다 찾을 것입니다. 이것은 값이 밀접하게 관련되어 있다는 강력한 신호입니다. "Cohesion"은 밀접하게 관련된 개념이 코드에서 가깝게 위치하는 객체 지향 프로그래밍의 원칙이므로이 원칙을 따르면이 세 가지 개념을 하나의 클래스로 통합 할 수 있습니다.

대부분의 프로그래머는 origin, destination 및 arrivalDeadline 대신에이 값이 사용되는 곳마다 단일 RouteSpecification 객체를 전달하는 것이 더 간단하다는 데 동의합니다.