아꿈사 스터디 발표자료 도메인 주도 설계 ch12,13

1. Domain-Driven Design12. 모델과 디자인 패턴의 연결 13. 더 심층적인 통찰력을 위한 리팩토링 아키텍트를 꿈꾸는 사람들cafe.naver.com/architect1 현수명 soomong.net #soomong

2. 도메인 주도 설계 1부.도메인 모델 만들기 2부.모델 주도 설계의 기본 요소 3부.더 심층적인 통찰을 향한 리팩토링 4부.전략적 설계

3. 12. 모델과 디자인 패턴의 연결 STRATEGY Pattern COMPOSITE Pattern 13. 더 심층적인 통찰력을 향한 리팩토링

4. 모델과 디자인 패턴의 연결 코드 내에 포함된 기술적인 측면을 다루는 패턴 디자인 패턴 VS 도메인 패턴 모델 내에 포함된 개념을 다루는 패턴

5. 패턴을 사용하는 이유 패턴에서 표준화된 요소를 찾음으로써 이미 알려진 해법이 있는 문제에 기력을 소모하지 않고 우리의 독특한 요구사항에 집중할 수 있다.

6. 패턴 설명 템플릿 패턴 이름 [개념을 나타내는 설명] [문제 논의] 문제 요약 문제 해결을 위한 논의. 해결책으로 이어짐. 그러므로 해결책 요약 결과. 구현 시 고려할 사항.예제 결과 내용. 관련 패턴 설명.

7. 1. Navigation The Language Problem Headline Picture Problem Body

8. 1. Navigation The Language Solution Solution Diagram

9. STRATEGY 패턴(전략) 패턴 이름 알고리즘을 여러 개 정의하고, 각 알고리즘을 일정한 형식으로 캡슐화한 다음 알고리즘을 교환할 수 있도록 만든다. 개념 설명

10. STRATEGY 패턴(전략) 여러 가지의 프로세스중 하나를 선택해야 하는 경우 적절한 프로세스를 선택하는 과정이 복잡함 다수의 프로세스가 있으니 복잡함 문제 논의 프로세스의 중심 개념과 변경되는 부분을 분리하자. 문제 해결을 위한 논의 그러므로 프로세스의 변화하는 부분을 따로 떼어내서 Strategy 객체로 만든다. 해결책 요약

11. STRATEGY 패턴예제(항로 탐색 정책) 예제 배달 일정표 배달하는 항로가 여러 개. - 가장 빠르게 목적지에 도착하는 항로 - 가장 저렴한 비용으로 목적지에 도착하는 항로

12. STRATEGY 패턴예제(항로 탐색 정책) 예제 항로를 계산하는 모든 곳에 항로를 선택하는 로직이 필요해짐 if( 가장 빠른 항로 ) … else( 가장 저렴한 항로 ) … 선택 로직을 없애고 항로를 Strategy 객체로만들어서 인자로 전달

13. STRATEGY 패턴예제(항로 탐색 정책) 예제

14. STRATEGY 패턴예제(항로 탐색 정책) 예제 항로가 또추가되는 경우 (ex.속도와 비용 둘 다 고려하는 항로) 패턴을 사용하지 않았다면 관련 로직if else 가 여기저기 흩어져 다른 코드와 엉킴 패턴을 사용한다면 결합도가 줄어드니 깔끔하게 추가가능 또 추가한다 해도 코드가 우아하게 유지됨

15. STRATEGY 패턴(전략) 구현 기술로서의 디자인패턴을 도메인 계층에서도 동일하게 사용가능. 디자인 패턴에 녹아있는 경험을 마음대로 활용하는 데는 아무런 문제가 없다. 결과 내용 관련 패턴

16. COMPOSITE 패턴(복합체) 패턴 이름 부분과 전체의 계층을 표현하기 위해 Composite 객체를 트리 구조로 만든다. 이로써 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있다. 개념 설명

17. COMPOSITE 패턴(복합체) 중요한 객체가 여러 개의 작은 부분이 조합되어 구성 그 작은 부분이 더 작은 부분으로 구성 더 작은 부분은 다시 더 세밀한 부분으로 구성 단지 크기만 더 작을 뿐 전체와 완전히 동일한 종류 문제 논의 공통적인 행위가 중복 동일한 수준에 위치한 다른 복합객체를 내부에 중첩할 수 없음 문제 해결을 위한 논의 그러므로 모든 구성요소를 포괄하는 추상 타입을 Composite 객체로 정의하라 클라이언트는 추상 타입만을 사용 해결책 요약

18. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제 전체 항로는 복잡 트럭 -> 철도 -> 선박 -> 육지

19. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제

20. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제 개발자 VS 도메인 전문가

21. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제 항로를 탐색하려면 서로 다른 타입의 객체를 처리해야 함

22. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제 COMPOSITE 적용! 추상객체

23. COMPOSITE 패턴 예제 (여러 항로로 구성된 배송항로) 예제

24. COMPOSITE 패턴(복합체) 다양하게 항로 구현 가능 항로의 한쪽 끝을 잘라서 새로운 끝에 연결 결과 내용 관련 패턴 FLYWEIGHT? 도메인모델과는 전혀 관련이 없는 디자인 패턴 제한된 수의 VALUE OBJECT를구현할 때는 괜찮음 하지만 ENTITY에는 안됨 개념적인 객체가 다른 개념적인 객체로 조합되는 COMPOSITE패턴과는 다름

25. 더 심층적인 통찰력을 향한 리팩토링 Refactoring Toward Deeper Insight 리팩토링시 주의점 도메인을 생각하자. 다른 방식으로 생각하자. 도메인 전문가와 계속 대화하자.

26. 더 심층적인 통찰력을 향한 리팩토링 Refactoring Toward Deeper Insight 시작. Initiation 도메인 리팩토링을 시작하는 방식은 다양. 코드 변경 말고 개발자들이 문제의 근본 원인은 도메인에 있다고 생각. 문제 위치 발견은 정말 어려운 일. 조사팀. Exploration Teams 개선안을 조사 도메인을 잘 아는 개발자 2 + 도메인 전문가. 모여서 브레인스토밍- 구현 - 브레인스토밍- 구현 자기 결정. TF 비슷 범위와 휴식. 작은 것을 선택하고 집중. 유비쿼터스 언어의 사용. 도메인 전문가가 알아들을 수 있는 언어로.

27. 더 심층적인 통찰력을 향한 리팩토링 Refactoring Toward Deeper Insight 선행기술. Prior Art 항상 바퀴를 다시 발명할 필요 없음. 분석패턴 사용. 하지만 적절히. 디자인 패턴 활용. 하지만 적절히. 개발자를 위한 설계. A Design for Developers 리팩토링 -> 유연한 설계 -> 쉬운 리팩토링& 사이드이펙트 없음 -> 개발자 정신적 부담 사라짐

28. 더 심층적인 통찰력을 향한 리팩토링 Refactoring Toward Deeper Insight 타이밍. Timing - 변경이 완벽하다고 자신할 때까지 기다리면 너무 늦다. - 코드 변경에 따르는 위험과 변경에 소요되는 개발자의 시간 비용은 인식하지만 부자연스러운 설계와 이로 인한 비용은 쉽게 깨닫지 못한다. - 리팩토링이 꼭 필요함 -> 위에선 변경 안 된다 -> 당위성을 열심히 설명 -> 그래도 안 된다 -> 시간이 지나서 코드가 더 복잡해짐 -> 개발자도 포기 or 몰래 리팩토링 - 소프트웨어 개발은 변경의 이익과 변경 안 했을 때의 손실을 정확하게 계산할 수 있는 예측 가능한 프로세스가 아니다. - 리팩토링이 필요한 경우 - 이해하고 있는 도메인이 설계에 표현X - 중요한 개념이 설계에 암시적으로 표현 - 설계를 더욱 유연하게 만들 기회가 보이는 경우 - But 출시 전날에 리팩토링을 해서는 안됨

29. 더 심층적인 통찰력을 향한 리팩토링 Refactoring Toward Deeper Insight 위기를 기회로. Crisis as Opportunity 찰스 다윈의 진화론 발표 -> 한 세기 이상 지속 -> 1970년대 한 순간에 단속 평형론으로 대체 보통의 리팩토링은 매우 안정적인 상태로 진행 But 더 심층적인 통찰력을 향한 리팩토링은 그렇지 않음. 어느 순간 갑자기 모든 것을 뒤흔드는 통찰력 위기처럼 보임. 하지만 팀이 새로운 이해 수준에 도달했다는 의미임. 즉 기회임. 한 단계 향상된 관점으로 기존 모델을 보면 결함투성이로 보임. ( 영화 속 정우성 보다가 옆에 남친보면 오징어 )

30. Reference 도메인 주도 설계 http://www.yes24.com/24/goods/5312881 러시아인형 : http://www.thisisgame.com/board/files/0/img/610-20070806111716_aa5af54e.jpg

31. 감사합니다