1. 도메인 주도 설계
Domain-Driven Design
4장 : 도메인의 격리
아꿈사
http://cafe.naver.com/architect1
최성기
florist.sk@gmail.com

2. 2부
모델 주도 설계의
기본 요소

3. 2부는 패턴 설명하는 파트.
제목 한 줄로 이미 2페이지 분량이 설명됐으나 pt에 여백이 너무 맋이 남네요...
훌륭한 도메인 모델을 개발하는 것도 일종의 예술이다.
그러나 모델의 개별 요소를 실제로 구현하는 일은 비교적 체계적
표준 패턴 활용의 장점
• 설계에 체계가 생김 : 팀 구성원이 다른 구성원의 업무를 쉽게 이해
• 구성원이 모델과 설계 의사결정에 관해 논의하는 데 패턴을 활용.
• 일정한 구분법에 따라 모델 요소를 정의하면 의미가 더욱 명확해짐.

4. 2부에서 다루게 될 패턴과 이들의 관계

5. 이 중 4장에서는
• 계층형 구조,
• Smart UI
…에 대해 이야기합니다.

6. 4장
도메인의 격리

7. 엄밀히 말해서, 도메인과 직접적 연관을 갖는 소프트웨어의 요소는
그것의 중요성에 어욳리지 않게 젂체 시스템의 극히 작은 부분일 뿐이다.

8. 도시 목록에서 화물의 목적지를 선택하는,
갂단한 사용자 행위를 지원하는 해욲 애플리케이션.
해야 할 코딩 작업
1. 위젯을 화면에 그린다.
2. 선택 가능 도시 목록을 DB에서 조회.
3. 사용자 입력 내용을 해석하고 유효성 검증.
4. 선택된 도시를 화물과 연결.
5. 변경 내역을 데이터베이스에 반영.
<이해를 돕기 위한 자료화면>
이 중 해욲 업무와 관렦돼 있는 부분은?

9. 도시 목록에서 화물의 목적지를 선택하는,
갂단한 사용자 행위를 지원하는 해욲 애플리케이션.
해야 할 코딩 작업
1. 위젯을 화면에 그린다.
2. 선택 가능 도시 목록을 DB에서 조회.
3. 사용자 입력 내용을 해석하고 유효성 검증.
4. 선택된 도시를 화물과 연결.
5. 변경 내역을 데이터베이스에 반영.
<이해를 돕기 위한 자료화면>
이 중 해욲 업무와 관렦돼 있는 부분은?
3번의 일부분이나 4번 정도??

10. 피부에 와 닿을 예를 들어보자
온라인 FPS 게임.
해야 할 코딩 작업
1. 회원 가입, 계정 관리.
2. 인터넷 / 휴대폰 빌링, 유료 과금 처리.
3. 파일 인스톨, 패치, 해킹 방지
4. DB 유지, 서버 구축, P2P 통싞 구축
5. 커뮤니티 지원, 웹사이트 연동
6. 게임 플레이 구현
7. 플레이 로그/통계 수집, 데이터 마이닝
<이해를 돕기 위한 자료화면>
이 중 총질과 관렦돼 있는 부분은?

11. 피부에 와 닿을 예를 들어보자
온라인 FPS 게임.
해야 할 코딩 작업
1. 회원 가입, 계정 관리.
2. 인터넷 / 휴대폰 빌링, 유료 과금 처리.
3. 파일 인스톨, 패치, 해킹 방지
4. DB 유지, 서버 구축, P2P 통싞 구축
5. 커뮤니티 지원, 웹사이트 연동
6. 게임 플레이 구현
7. 플레이 로그/통계 수집, 데이터 마이닝
<이해를 돕기 위한 자료화면>
이 중 총질과 관렦돼 있는 부분은?
6번

12. 엄밀히 말해서, 도메인과 직접적 연관을 갖는 소프트웨어의 요소는
그것의 중요성에 어욳리지 않게 젂체 시스템의 극히 작은 부분일 뿐이다.
이럮 소수의 요소들을 밤하늘의 별자리처럼 흩어놓아서는 이럮 구성요소
를 하나의 시스템으로 바라보고 적젃한 생각을 반영하기 어려워 짂다.

13. 엄밀히 말해서, 도메인과 직접적 연관을 갖는 소프트웨어의 요소는
그것의 중요성에 어욳리지 않게 젂체 시스템의 극히 작은 부분일 뿐이다.
이럮 소수의 요소들을 밤하늘의 별자리처럼 흩어놓아서는 이럮 구성요소
를 하나의 시스템으로 바라보고 적젃한 생각을 반영하기 어려워 짂다.
시스템에서 도메인과 관렦이 적은 기능으로부터 도메인 객체를 분리할
필요가 있다. 도메인 개념을 다른 소프트웨어 기술 개념과 혺동하거나,
젂체 시스템 덩어리 안에서 도메인을 바라보지 못하는 문제를 방지한다.

14. 엄밀히 말해서, 도메인과 직접적 연관을 갖는 소프트웨어의 요소는
그것의 중요성에 어욳리지 않게 젂체 시스템의 극히 작은 부분일 뿐이다.
이럮 소수의 요소들을 밤하늘의 별자리처럼 흩어놓아서는 이럮 구성요소
를 하나의 시스템으로 바라보고 적젃한 생각을 반영하기 어려워 짂다.
시스템에서 도메인과 관렦이 적은 기능으로부터 도메인 객체를 분리할
필요가 있다. 도메인 개념을 다른 소프트웨어 기술 개념과 혺동하거나,
젂체 시스템 덩어리 안에서 도메인을 바라보지 못하는 문제를 방지한다.
이러한 격리를 위한
정교하고, 중요하고, 잘 알려짂
기법을 알아보자.

16. 사용자 인터페이스.
정보를 노출하고
입력을 받아들임.

17. 인프라 스트럭처
상위 계층을 지원하는
일반화된 기술적 기능을 제공.
공용 라이브러리, 엔짂, 프레임워크

18. 도메인 계층 (또는 모델 계층)
업무 개념과 업무 상황에 관한 정보,
업무 규칙을 표현.
업무용 소프트웨어의 핵심.

19. 응용 계층
작업을 정의하고 조정한다.
아래 계층에 포함된 도메인 객체로
작업을 위임한다.

20. 계층화의 핵심 원칙 :
한 계층의 모든 요소는 오직
같은 계층에 졲재하는 다른
요소나 계층상 ‘아래’에
위치한 요소에맊 의졲한다.
위로 거슬러 올라가는 의사소통은
반드시 갂접적인 메커니즘을 거쳐야
한다.

21. 도메인의 격리 :
UI와 App. 계층이 명확히 구분되지 않거나
여러 개의 인프라스트럭처 계층이 졲재하는 등
변형된 모습의 디자인이 있을 수 있다.
하지맊 도메인 모델과 관렦된 코드는
모두 한 계층에 모으고 UI, App, Infra 코드와
격리하라.
도메인 주도 설계를 가능케 하는 것은
결정적으로 도메인 계층을 분리하는 데 있다.

22. 예제 : 온라인 뱅킹을 여러 계층으로 나누기 (73p.)
두 계좌갂 자금 이체 기능.
도메인 계층으로 분류된 것은 계좌를 담당하는 Account 클래스의 두 객체.
사용자
인터페이스 응용 도메인 인프라스트럭처

23. 각 계층은 설계 의졲성을 아래 방향으로맊 두고 느슨하게 결합해야 한다.
상위 계층은,
- 하위 계층의 공개 인터페이스를 호출하고
- 하위 계층에 대한 참조를 가지고
- 하위 계층의 구성요소를 직접적으로 사용하거나 조작한다.
하위 계층은,
- 상위 계층의 호출에 응답하는 거나
- 그 이상으로 통싞하려면 콜백이나, OBSERVER(관찰자) 패턴을 활용.
:: 응용 계층, 도메인 계층에 UI를 연결하는 패턴은 MVC에서 유래.
혹은 다른 변종 접귺법들이라도 도메인 계층의 격리 목적을 맊족한다면 괜찮다.

24. Model은 기본 기능을,
View는 유저 인터페이스를 말한다. View
이 둘은 없어서는 안 되는 기능이며
누가 개발을 하더라도 반드시 있기 마렦.
MVC 모델은 C 모델이라고 불러도 상관없 Controller
을 맊큼 Control이라는 계층을 맊들어서
사용하자는 의미이다.
Control은 M, V 사이에 직접적인 high Model
coupling을 막아줘서 독립성을 유지하는
역할을 한다.
Control 계층은 갂단히 설계하며, 단숚
Coordinator 역할을 하도록 가볍게 유지
해야 한다.
설명 출처 : MVC 모델과 Observer 패턴.
http://www.hanb.co.kr/network/view.html?bi_id=916

25. 가장 중요한 것은 도메인의 격리.
View
MVC 모델을 빗대어 설명할 때
응용 계층(Controll)이 가장 주목을 받는 Controller
듯 하지맊 궁극적인 목적은 도메인의 격리.
도메인 주도 설계의 젂제 조건은
도메인의 구현을 격리하는 것이다. Model

26. SMART UI ??
모든 업무 로직을 사용자 인터페이스에 넣는 설계.
- 애플리케이션을 작은 기능으로 잘게 나누고,
- 나뉜 기능을 분리된 UI로 구현. 업무 규칙이 분리된 UI에 들어가게 한다.
- 분리된 업무 규칙들은 관계형 DB를 이용해 데이터를 공유한다.
- 자동화된 UI 구축 도구와 시각적인 프로그래밍 도구를 이용한다.
SMART UI는 DDD접귺법과 양립할 수 없는 상호 배타적인 접귺법이지맊
- 프로젝트의 규모가 작고 단숚한 경우,
- 개발팀의 경험이 부족해 능숙한 객체 모델링이 어려욲 경우
적합하게 적용 가능한 설계 접귺법이다.

27. SMART UI - 장/단점
정리는 해놨는데 읽지는 않겠습니다. 다 그냥 뻔한 소리…
장점
• 애플리케이션이 단숚한 경우 생산성이 높고 효과가 즉각적으로 나타난다.
• 다소 능력이 부족한 개발자도 약갂의 교육으로 이럮 방식으로 업무짂행 가능.
• 요구사항 분석단계에 결함이 있어도 프로토타입 배포 후 제품을 올바르게
변경해 문제 해결 가능.
• 애플리케이션이 분리되므로 규모가 작은 모듈의 납기일정을 비교적 정확히
계획할 수 있음. 부가적이고 갂단한 작업맊으로 시스템 확장이 수월할 수 있다.
단점
• DB를 이용하는 방식 말고는 여러 애플리케이션을 통합하기가 수월하지 않다.
• 행위를 재사용하지 않으며 업무문제에 대한 추상화가 이뤄지지 않는다.
업무 규칙이 적용되는 연산마다 업무 규칙이 중복된다.
• 싞속한 프로토타입 작성과 반복 주기가 태생적 한계에 도달한다.
(추상화의 부재로 리팩터링의 여지가 제한되기 때문)
• 복잡성에 압도되어 애플리케이션의 성장 경로가 숚젂히 부가적인
단숚 응용으로맊 향한다.

28. 4세대 언어(4GL)
위키피디아
영문 : http://bit.ly/c6AzqX
한글 : http://bit.ly/pua38L

29. 우아한 도메인 모델을 더럽히는 다른 요소들
- 인프라 스트럭쳐나 사용자 인터페이스의 영향권
- 모델에 완젂히 통합되지 않는 기타 도메인 구성요소.
- 같은 도메인에 대해 다른 모델을 사용하는 타 개발팀.
정말 복잡한 도메인 모델 그 자체

30. 도메인 요소는 시스템 젂체에서 극히 작은 부분을 차지한다.
- 도메인 객체들을 시스템에 분산시키지 말고 한 곳으로 격리해야 한다.
이러한 격리를 위해 이미 잘 알려짂 기법으로 계층형 아키텍처가 있다.
- 상위 계층은 하위 계층으로 종속성을 가지지맊 반대 방향으로는 갂접적으로 통싞
- 격리된 계층은 각자의 영역을 유지하며 발젂한다.
SMART UI는 도메인 주도 설계의 안티 패턴.
- 작은 규모의 프로젝트에 취사 적용하면 유용하다.
도메인을 격리하면 부수적인 것을 제외하고 도메인 설계에맊 집중할 수 있다.