2. 디자인패턴의 활용
• 디자인패턴은 순수 기술적 용어로 작성됨.
• 도메인 모델링과 디자인에서
디자인패턴 일부를 적용할 수 있음.
• DDD에서 사용할려면, 아래 2가지 측면으로 볼 수 있음
‣ 코드안에서 적용되는 기술적 디자인 패턴.
‣ 모델안에서 적용되는 개념적 패턴.
12년 11월 3일 토
3. Strategy
(A.K.A. Policy)
• 알고리즘군을 정의.
• 각 알고리즘을 캡슐화.
• 알고리즘을 교체가능하도록.
12년 11월 3일 토
4. Strategy
• 도메인 모델에서 적절한 프로세스를 교체할 수 있어야 함.
• 수많은 프로세스중에서
적절한 프로세스를 선택하는 것은 어렵다.
• 하나의 프로세스가
여러가지 업무를 혼합하여 수행하면 모델링하기 어렵다.
• 프로세스의 주 개념에서 변경되는 부분을 분리.
12년 11월 3일 토
5. Strategy
• 프로세스의 변화되는 부분을
모델내에서 "Strategy" 오브젝트로 격리.
• 프로세스의 행위와 규칙을 분리.
• "Strategy" 패턴에 맞게 변경되는 부분을 구현.
• 이러한 구현은 각각 다른 방법으로 업무를 수행.
12년 11월 3일 토
6. 경로 탐색 정책
• Routing Service는
경로 리스트를 생성.
• 가장 빠른 경로 리스트,
가장 저렴한 경로 리스트.
findFastest(Specification):Itinerary
findCheapest(Specification):Itinerary
12년 11월 3일 토
7. 경로 탐색 정책
find(Specification, LegMagnitudePolicy):Itinerary
12년 11월 3일 토
8. 주의점
• 도메인 레이어에 기술적 디자인 패턴 적용시,
레이어를 추가해서 작업해라.
• 추가된 레이어에 전략과 정책을 넣고 분리해라.
• 객체가 늘어난다면, 공유하여 사용할 수 있도록,
객체에 상태를 가지지 않도록 만들어라.
12년 11월 3일 토
9. Composite
• 부분과 전체를 표현
하기 위함.
• 개별 객체와 복합
개체를 동일하게 처
리.
12년 11월 3일 토
10. Composite
• 복잡한 도메인인 경우,
중요한 오브젝트는 임의의 깊이를 가지는
부분 오브젝트들이 중첩되어 구성된다.
• 각 레벨 오브젝트는 구분할 수 도 있지만,
각 부분 오브젝트를 동일한 하나의 전체로 다룰 수 있다.
12년 11월 3일 토
11. Composite 미적용
• 모델에 중첩된 컨테이너의 연관성이 반영되지 않으면,
각 계층의 공통된 행위는 중복되고, 유연성이 떨어진다.
• 컨테이너가 다른 컨테이너를 포함할 수 없고,
컨테이너를 포함할 수 있는 깊이는 고정된다.
• 클라이언트 입장에서는 개념적으로 차이가 없어도,
각 계층마다 다른 인터페이스로 관리하고,
정보를 수집하기 위한 순회 작업은 복잡해진다.
12년 11월 3일 토
12. Composite 적용
• COMPOSITE의 모든 개체를 포함하는 추상타입을 정의.
• 컨테이너는 정보를 수집하고 반환하는 메소드 정의하고,
"단말" 노드는 자신이 가진 정보를 기반하여 구현.
• 클라이언트는 추상 타입과 통신하며,
컨테이너와 단말을 구별할 필요가 없다.
12년 11월 3일 토
19. 13. 더 심층적인
통찰력을 향한 리팩터링
• 심층적인 리팩터링을 하기 위해서.
‣ 도메인에 주력하라.
‣ 다른 관점으로 현상과 사물을 바라보도록 노력하라.
‣ 도메인 전문가와 지속적으로 대화하라.
12년 11월 3일 토
20. 리팩터링
• 한두명의 개발자가 코드를 보며 개선의 여지를 찾차 수정하
고, 테스트하여 검증한다.
• 리팩터링 과정에서 도메인에 대한 통찰력을 추구하면 더 폭
넓은 컨텍스트를 만들 수 있다.
12년 11월 3일 토
21. 시작
• 도메인 전문가없이 작성된 모델과,
새로운 요구 사항이 자연스럽게 추가되지 못하는 상황에서
• 개발자는 근본적으로 도메인 모델에서 개념이 빠져거나,
관계에 오류가 있다고 가정한다.
• 도메인을 심층적으로 이해한 개발자가 더 명쾌하고 유용한
모델로 만드는 것이 리팩터링이다.
12년 11월 3일 토
22. 조사팀
• 코드 변경에 착수한 개발자는 뛰어난 2명의 개발자를 선발.
• 도메인 전문가도 참여.
• 30분에서 1시간 30분정도 브레인스토밍 진행.
• UML, 시나리오 진행.
• 만족스러운 결과라면 코드로 구현.
12년 11월 3일 토
23. 선행 기술
• 브레인스토밍, 서적, 실무 개발자의 추상적인 개념등으로
부터 정보를 얻을 수 있다.
• 분석 패턴을 통해 다른 이의 경험을 활용.
현재 도메인의 소프트웨어를 개발한 경험을 활용.
• 디자인패턴이 구현 요구와 모델 개념에 적합할 경우 활용.
• 수학이나 술어 로직.
12년 11월 3일 토
24. 개발자를 위한 설계
• 다른 코드와 통합, 반복적 코드 수정, 심층적인 리팩터링을
통해 유연한 설계
• 유연한 설계는 설계의 의도, 코드의 영향 예측, 정신적 부담
을 줄임.
• 가장 빈번하게 발생하는 부분은 유연하게,
자주 변경되지 않는 부분은 단순하게.
12년 11월 3일 토
25. 타이밍
• 수정하기 위해 완벽할 때까지 기다리지 마라.
‣ 도메인을 이해하고 있는 바가 설계에
적용되지 않은 경우.
‣ 중요한 개념이 설계상에 암시적으로 표현된 경우.
‣ 설계상 중요 부분이 더 유연하게 만들 수 있는 경우.
12년 11월 3일 토
26. 위기를 기회로
• 리팩터링이 안정적인 상태로 진행되는 것 처럼 보이지만,
심층적인 통찰력을 향한 리팩터링은 그렇지 않다.
• 모델을 일정 기간동안 꾸준히 정제하다 보면,
모든 것을 뒤흔드는 통찰력을 얻는다.
• 위기로 보이는 이 시점에서 더 훌륭한 모델을 생각해낼 수
있다.
• 그리고 지속적인 정제 과정이 다시 시작된다.
12년 11월 3일 토
