9장 도메인 주도 설계

1,713 views

Published on

도메인 주도 설계 아꿈사 스터디 9장 발표자료

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,713
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

9장 도메인 주도 설계

  1. 1. 도메인주도 설계<br />9장. 암시적인 개념을 명확하게<br />cafe.naver.com/architect1/<br />전효성<br />
  2. 2. 심층 모델<br />문제의 본질을 파악<br />무엇이 문제인가<br />해결책은 어떤것이 있나<br />중요한 개념들<br />해결책에 대한 추상화<br />2<br />
  3. 3. 9장의 주요 내용<br />암시적인 개념  명확화<br />우리가 흔히 아는 내용들<br />3<br />
  4. 4. 개념 파헤치기<br />어떻게 숨어있는 개념을 캐치할까?<br />팀에서 사용하는 언어<br />찝찝한 설계<br />모순된 요구사항<br />전문가의 의견 검토<br />도메인 관련 문서 조사<br />실험<br />4<br />
  5. 5. 개념 파헤치기<br />언어에 귀를 귀울여라<br />어색한 부분을 조사하라<br />모순점에 대해 깊이 고민하라<br />시도하고 또 시도하라<br />5<br />
  6. 6. 언어에 귀를 귀울여라<br />모델을 발전시키는 것들<br />도메인 전문가가 언급한 새로운 단어<br />전문가가 교정해 주는 단어, 개념들<br />특정 문구를 언급시 도메인 전문가의 당혹스러운 표정?<br />6<br />
  7. 7. 어색한 부분을 조사하라<br />어색한 설계의 정의<br />말로 표현하기 힘들정도로복잡한 작업을 하는 프로시저<br />새로운 요구사항으로 안한복잡도 증가<br />도메인 전문가의 역할<br />누락된 개념, 부자연스러운 흐름 발견<br />아이디어 검증<br />개발자의 역할<br />도메인 전문가가 해당 역할을 잘 수행하도록 돕는 것<br />7<br />
  8. 8. 모순점에 대해 깊이 고민하라<br />모순의 발생 원인<br />용어를 다르게 사용<br />도메인 이해 부족<br />실제로 다양한 관점<br />심층 모델을 발전시키는 중요한 단서<br />8<br />
  9. 9. 일반적으로….<br />모순은 그렇게 흥미롭지도 않고 심오한 내용도 없더라.<br />모든 모순을 해결하는 것은 비현실적, 바람직하지 않다.<br />그러나, 심사숙고하면서 숨겨져 있던 사실을 밝히는 계기가 된다.<br />9<br />
  10. 10. 서적을 참고하라<br />분명해 보이는 사실도 확인하자.<br />다양한 서적 참고<br />10<br />
  11. 11. 시도하고 또 시도하라<br />6<br />쓸만한 지식을 발견하기 까지 발생한 커뮤니케이션 오류<br />모든 것을 고민하여 가는 것보다 try and learn하여 가는 것이 빠르다.<br />11<br />
  12. 12. 12<br />
  13. 13. 다소 불명확한 개념을 모델링 하는 법<br />명시적인 제약조건<br />도메인 객체로서의 프로세스<br />모델에 반영되는 개념들<br />명사, 동사<br />13<br />
  14. 14. 명시적인 제약조건<br />제약조건 ( constraint )<br />대부분암시적인 상태로 존재<br />명시적으로 표현하자.<br />‘명사’로 제약에 대한 의견 교환<br /> Before After<br />14<br />
  15. 15. 도메인 객체로서의 프로세스<br />프로세스를 도메인 모델에 표현하는 방법<br />캡슐화<br />기본적인 방법<br />알고리즘 자체 or 부분을 객체화<br />여러가지 프로세스가 존재할 경우<br />각각 객체는 다른 STRATEGY를 표현(12장)<br />15<br />
  16. 16. 도메인 객체로서의 프로세스<br />명시적으로 표현해야 할 프로세스<br />도메인 전문가가 이야기 하는 프로세스<br />숨겨야 할 프로세스<br />컴퓨터 프로그램 상의 매커니즘<br />결론 : 제약사항과 프로세스를 모델의 요소로 간주해야 한다.<br />16<br />
  17. 17. 이런 것들을 잘하려면?<br />개념의 명확화  SPECIFICATION<br />SPECIFICATION<br />마틴파울러& Evans 1997 개발<br />자세한 내용은 10장에<br />특정 종류의 규칙을 표현하는 간결한 수단 제공<br />조건로직과 규칙의 분리 유도<br />17<br />
  18. 18. SPECIFICATION (명세)<br />규칙을 처리하는 방법 <br />자주 변경되지 않는 것<br />(도메인 계층)<br />Date<br />자주 변경되는 것<br />(응용계층)<br />계정정보<br />지불이력<br />회사정책<br />18<br />
  19. 19. SPECIFICATION (명세)<br />또 다른 방법, 논리 프로그래밍 <br />rule-base system<br />술어( predicate )  bool<br />구현하기 어렵다.<br />19<br />
  20. 20. SPECIFICATION (명세)<br />이 책에서 제시하는 방법<br />20<br />
  21. 21. SPECIFICATION?<br />객체 안의 “평가 로직들”을 Specification객체로 분리<br />Specification 객체의 특징<br />평가하는 객체<br />Value object<br />다양한평가 객체들을 FACTORY를 통해 생성 가능<br />PATTERN임.<br />21<br />
  22. 22. SPECIFICATION 의 적용과 구현<br />SPECIFICATION PATTERN 사용용도<br />검증( validation )<br />선택( selection )<br />요청 구축( building to order )<br />패턴<br />22<br />
  23. 23. SPECIFICATION의 적용과 구현검증( validation )<br />특정한 조건에 부합하는 판단하기 위한 객체의 개별 테스트<br />다양한 invoice 평가 전략이 존재<br /><ul><li>다양한 Invoice specification 객체를 이용하여 Invoice객체를 검증</li></ul>23<br />
  24. 24. SPECIFICATION의 적용과 구현선택( or 질의 )<br />특정 조건 기반으로 객체 컬렉션 일부를 선택<br />예, “체납된 송장을 보유한 모든 고객 목록 나열”<br />DB를 통한 접근<br />SQL쿼리는 도메인 계층에만 존재<br />REPOSITORY, DOUBLE DISPATCH 패턴 사용<br />24<br />
  25. 25. SPECIFICATION의 적용과 구현선택( or 질의 )<br />25<br />
  26. 26. SPECIFICATION의 적용과 구현요청구축( 생성 )<br />SPECIFICATION 패턴을 이용하여 객체를 생성<br />선언적으로 객체 생성<br />유연성 증가<br />테스트 용이<br />동작하는 프로토타입 작성 용이<br />Mock object<br />26<br />
  27. 27. SPECIFICATION의 적용과 구현요청구축( 생성 )<br />Example – 화학용품 보관<br />화학용품 특징<br /><ul><li>TNT  강화 컨테이너
  28. 28. 생물학적 시료  강화 컨테이너에 보관 금지
  29. 29. 암모니아  통풍 컨테이너</li></ul>27<br />
  30. 30. 결론<br />도메인을 잘 이해하자.<br />암시적인 근거들을 잘 파악해서 모델에 반영하자.<br />객체 생성/선택/검증 로직을SPECIFICATION을 이용하여 작성하자.<br />28<br />

×