개발자들이 토의 중에 단서를 얻거나 설계상에 암시적으로 존재하는 개념을 인지하면 도메인
모델과 관련 코드를 대량으로 변환하게 되며，그 후 하나 이상의 객체와 객체 간의 관계를 활용
해 모델 내에 해당 개념을 명확하게 표현하게 된다

개념 파헤치기

• 개발자는 잠재해 있는 암시적인 개념을 드러내는 단서에 민감해야 하며, 이따금 한발 앞서 미리 암시적인 개념을 찾아야 할 때도 있다.

언어에 귀 기울여라

도메인 전문가가 사용하는 언어에 귀 기울여라. 복잡하게 뒤얽힌 개념들을 간결하게 표현하는
용어가 있는가? 여러분이 선택한 단어를 (아마도 더 적절하게) 고쳐주는가? 여러분이 특정 문구
를 이야기할 때 도메인 전문가의 얼굴에서 곤혹스러운 표정이 사라지는가? 이 모두가 바로 모델
에 기여하는 개념의 실마리에 해당한다

• 새로운 단어를 듣게되면 명료하고 유용한 개념을 찾기 위한 대화와 지식탐구로 이어짐
• 설계상의 어디에도 포함돼있지 않은 단어 사용은 위험 신호이며, 이를 설계에 포함시켜 모델과 설계를 향상시킬 수 있는 기회가 되기도

예제

해운 모델의 누락된 개념에 귀 기울이기

• 화물 예약 기능을 제공하는 애플리케이션을 개발해 둔 상태

• 다음으로 화물을 적재/하역하는 작업 순서를 효율적으로 조직하는 “운영 지원” 애플리케이션 개발하는 일

• 그림 9-1 향로 설정 엔진

  

• 그림 9-2 대화 중에 그린 다이어그램

  

• 그림 9-3 리팩터링한 결과

  

• 누락된 개념에 주의해서 귀를 기울인 결과 “운항일정”이 해운 전문가에게 얼마나 중요한 개념인지 알게 됨

• ‘Itinerary’ 객체로 리팩터링한 결과로의 이점

  1. Routing Service의 인터페이스를 좀더 표현력 있게 정의
  2. Routing Service에서 예약 데이터베이스 테이블로의 결합 제거
  3. 예약 애플리케이션과 운영 지원 애플리케이션 간의 (Itinerary 객체를 공유하는) 관계를 명확하게 표현
  4. Itinerary로부터 예약 보고서와 운영지원 애플리케이션 모두에 대한 적재/하역 시간 도출 이 가능해져서 중복 코드가 줄어듦
  5. 예약 보고서로부터 도메인 로직을 제거하고 별도의 도메인 계층으로 옮김
  6. UBIQUITOUS LANGUAGE를 확장함으로써 개발자와 도메인 전문가，그리고 개발자 간의 모델과 설계에 대한 좀더 정확한 논의가 가능해짐

어색한 부분을 조사하라

• 필요한 개념이 늘 대화나 문서로 인식할 수 있을만큼 확연히 드러나 있지는 않다
• 어색하거나 누락된 사실을 깨달아도 모르지만, 이때 도메인 전문가가 발견할 수 있게끔 해야한다

예제