• 복잡하게 동작하는 소프트웨어에 좋은 설계가 결여돼 있다면 요소들을 리팩터링하거나 결합 하기가 어려워짐

• 레거시 코드로 인한 중압감에 시달리지 않고 프로젝트 진행을 촉진하려면 변경을 수용하고 즐겁게 작업할 수 있는 설계가 필요

  → 유연한 설계

• 유연한 설계는 심층 모델링을 보완

• 너무 과도한 추상 계층과 간접 계층이 존재하면 오히려 유연성에 방해

• 단순한 모델을 창조하거나 심지어 사용하자면 상대적으로 복잡한 설계 솜씨가 필요

• 개발자는 두 가지 역할 수행

  1. 클라이언트 개발자 역할로서 설계 특징을 활용해 도메인 객체를 애플리케이션 코드나 다른 도메인 계층의 코드와 통합
  2. 설계는 설계 자체를 변경하는 개발자도 뒷받침

• 그림 10-1 유연한 설계에 기여하는 패턴

  

INTENTION-REVEALING INTERFACE

(의도를 드러내는 인터페이스)

• 도메인 주도 설계를 적용할 때는 의미 있고 가치 있는 도메인 로직에 관해 생각
• 명확하게 표현된 규칙없이 암묵적인 규칙에 따라 실행되는 코드를 이해하려면 소프트웨어 프로시저를 구성하는 각 단계를 기억

개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치는 사라진다. 
원래의 개발자가 아닌 다른 개발자가 구현 내용을 토대로 객체나 연산의 목적을 추측해야 한다면 
새로운 개발자는 우연에 맡긴채 연산이나 클래스의 목적을 짐작할 가능성 이 있다. 추측한 바가 원래의 취지에 
어긋난다면 당장은 코드가 정상적으로 동작했다고 하더라도 설계의 개념적 기반은 무너지고 두 개발자는 
서로 의도가 어긋난 상태로 일하게 된다

• 타입 이름, 메서드 이름, 인자 이름이 모두 결합되어 INTENTION-REVEALING INTERFACE를 형성

수행 방법에 관해서는 언급하지 말고 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여하라. 
이렇게 하면 클라이언트 개발자가 내부를 이해해야 할 필요성이 줄어든다. 이름은 팀원들이 그 의미를 쉽게 
추측할수있게 UBIQUITOUS LANGUAGE에 포함된 용어를 따라야 한다. 클라이언트 개발자의 관점에서 
생각하기 위해 클래스와 연산을 추가하기 전에 행위에 대한 테스트를 먼저 작성하라.

예제

리팩터링: 페인트 혼합 애플리케이션

• 페인트 상점에서 사용하게 될 프로그램은 고객에게 규격 페인트를 혼합한 결과를 표시

• 그림 10-2 하나의 도메인 클래스만을 포함하는 초기의 설계 모습

  

• 두 개의 Paint를 혼합하고 그 결과로 용량은 더 늘어나고 색상은 혼합