우리는 시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있음
계층형 아키텍처(LAYERED ARCHITECTURE)
객체지향 프로그램에서는 종종 비즈니스 객체 안에 UI, DB 등의 보조적인 코드를 넣고, 부가적인 업무 로직은 UI 위젯과 DB 스크립트에 들어가게 된다
도메인에 관련된 코드가 도메인과 관련이 없는 다른 코드를 통해 널리 확산될 경우 추론하기가 어려워진다
모델 주도적인 객체 구현이 힘들어지고 자동화된 테스트 어려워짐
계층화의 가치는 더욱 응집력 있는 설계가 가능해지며, 설계를 훨씬 더 쉽게 이해할 수 있다
네 가지 개념적 계층
복잡한 프로그램을 여러 개의 계층으로 나누고, 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시켜야 한다
예제 - 온라인 뱅킹 기능을 여러 계층으로 나누기
은행 계좌를 유지하는 데 필요한 다양한 기능 제공
그 중 사용자가 두 계좌 번호와 일정 금액을 입력하거나 선택하면 이체가 시작되는 자금 이체 기능
그림 4-1 객체는 자신이 속한 계층에 맞는 책임을 수행하며, 같은 계층에 존재하는 객체와 더 결합된다
눈여겨봐야 할 것은 응용 계층이 아닌 도메인 계층에서 주요 업무 규칙을 책임
→ "모든 대변(debit)에는 그것과 일치하는 차변(credit)이 있다"
질문: 도메인을 격리하지 않았을 때의 문제점을 완화해서 보여준다(p74 3번째 문단)
→ 도메인 격리를 더 했어야 된다는 말?
각 계층은 설계 의존성을 오직 한 방향으로만 둬서 느슨하게 결합
상위 계층은 하위 계층의 공개 인터페이스를 호출하고 하위 계층에 대한 참조나 직접적인 조작
하위 계층이 상위 계층과 소통해야 할 경우 콜백이나 관찰자 패턴 등을 활용 가능
분리의 주된 이점은 애플리케이션 계층이 단순해져서 본연의 책임에만 집중하게 되는 것
→ 메시지를 "언제" 보는지는 알아도 "어떻게" 보내는지 알 필요가 없어진다는 것