Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Domain-Driven-Design 정복기 1탄

2,730 views

Published on

오마이랩 사내 프레젠테이션

Published in: Technology
  • Be the first to comment

Domain-Driven-Design 정복기 1탄

  1. 1. DDD 정복기 1탄 @ jjo_ssoo
  2. 2. 정복기에 시작하기에 앞서 ■ 처음 들었던 DDD에서의 Domain? Domain이 설계의 중심? 관계형 데이터베이스에서 테이블의 각 속성이 가질 수 있는 값의 집합? 인터넷상에서 개인이 소유하고 있는 인터넷 주소? 각자 생각하는 Domain은 다 다를 것! DDD에서의 Domain은 다르다!
  3. 3. DDD ? What is the “Domain Driven Design”?
  4. 4. Domain- Driven- DESIGN 저자 : Eric Evans 이 책의 한줄 평 DDD를 공부하는 이들에게 성서와 같은 존재 (해석도 여럿이다.) by Gyuwon Yi
  5. 5. DDD 준비 단계 개발은 일정한 반복주기를 가지고, 반복주기를 토대로 진행되야 한다. Domain 전문가와 밀접한 관계에 있어야 한다.
  6. 6. DDD 복잡한 도메인을 다뤄야 하는 SW 프로젝트에 박차를 가하는 것을 목표로 삼는 사고방식이자 우선순위의 모음 소프트웨어는 도메인의 핵심 구성과 각 구성요소를 담고 있어야 한다. 이렇게 도메인과 조화된 소프트웨어를 만드는게 DDD의 목적
  7. 7. STEPs Analyze Domain Domain Ubiquitous Language Bounded Context Bounded Context Context Map Shared Kernel Etc) Define Entities, Aggregates, Services Entities Value Object Aggregates Services Etc) UI Application Domain Layer Infrastructure Layerd Architecture
  8. 8. ANALYZE DOMAIN DOMAIN으로 부터 얻는 것
  9. 9. Domain 사용자가 프로그램을 사용하는 대상영역 SW는 도메인의 문제를 해결하기 위한 수단 하나의 도메인은 하위 도메인으로 나눌 수 있다.
  10. 10. DOMAIN MODEL 도메인의 구성요소를 개념적으로 표현한 것 SW 전문가와 도메인 전문가가 만드는 것 도메인에 대한 이해가 필수! 어떤 특정한 다이어그램이 아니라 다이어그램이 전달하고자 하는 아이디어
  11. 11. DOMAIN MODEL 모델은 도메인 지식의 정수만을 뽑아 낸 것 모델은 팀 구성원이 사용하는 언어의 중추 모델과 핵심 설계는 서로 영향을 주며 구체화된다.
  12. 12. Ubiquitous Language 서로의 용어를 이해해야만 한다! 도메인 모델을 만들기 위해선 모호함이 없어야 한다. 만들어진 Ubiquitous Language는 보관이 필수!
  13. 13. Ubiquitous Language 도메인 모델 용어 Bounded Context 이름 기술적 디자인 패턴 DDD에서 소개하는 여러 패턴 이름 대규모 구조 용어 기술적인 용어 개발자가 이해하지 못하는 업무 관련 용어 모든 이들이 사용하지만 설계에 나타나지 않는 업무 관련 용어 (모델에 속하는 후보) 설계의 기술적 측면
  14. 14. Ubiquitous Language 설계의 세부사항은 코드에 담긴다. 문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안된다. 문서는 유효한 상태를 유지하고 최신 내용을 담고있어야 한다.
  15. 15. QUICKLY MODELING From Domain
  16. 16. Modeling Example 영화 예매 시스템 1. Reservation은 영화 정보ID, 좌석 정보, 요금정보를 갖는다. … Reservation : 영화 예매 정보, Movie: 영화 정보, Sitting : 좌석 정보, Rate: 요금 정보등
  17. 17. Modeling Example Reservation Model (이거보다 훨씬 풍성해져야 한다) Reservation ID MovieID Sitting Rate
  18. 18. Enitity 소프트웨어가 여러 과정을 거치는 과정에도 동일한 값을 유지하는 식별자를 지닌 유형의 객체 “Entity의 정체성에 초점을 맞추어야 한다. 의미에 따라 Entity를 분류한다면 모델이 더욱 투명해지고 구현은 견고해질 것이다.” By Eric Evans
  19. 19. Value Object 개념적 식별성이 없는, 어떤 특징을 묘사하는 객체 한번 만들어 지면 바뀌지 않는 객체 값 자체에만 의미가 있다.
  20. 20. Aggregate 일관성을 공유하는 데이터 집합 일관성을 유지해야될 객체들을 묶어 놓은 것 Root Entity : 접근 범위에 있는 가장 상위 Entity Aggregate은 Root Entity만을 통해 외부에서 접근 할 수 있다.
  21. 21. Aggregate 필요성 연관 관계를 줄이면서 복잡도가 감소한다. 많은 도메인 모델을 간단하고 이해가능한 수준으로 만들어 줄 수 있다.
  22. 22. Modeling Example Reservation Aggregate <<Value Object>> Rate … <<Entity>> (Root) Reservation Id: Guid MovieId: Guid Sitting : Sit Rate : Rate <<Value Object>> Sit …
  23. 23. Effective Modeling by Eric Evans 모델과 구현의 연계 모델을 기반으로 하는 언어 정제 풍부한 지식이 담긴 모델 기반 모델의 정제 브레인 스토밍과 실험 지속적인 학습
  24. 24. DDD를 왜 해야하는지? 놓치기 쉬운 이유
  25. 25. Why DDD? DDD 발표를 준비하면서 많은 내용들의 글을 보았지만 DDD에 대한 요소들의 설명은 많이 찾아 볼 수 있었다. 하지만… 요소들의 설명들만큼 찾기 힘들었던 DDD의 존재이유…. 덕분에 Eric Evans 님의 말을 이해하려고 노력함
  26. 26. Eric Evans 가 말한 Domain 하나의 도메인은 세상의 어떤것! 우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분! 힘있고 유연한 소프트웨어를 만들게 해준다!
  27. 27. 내가 생각하는 DDD의 장점 3. 어느 분야나 트렌드는 변한다. DDD로 잘 설계 되어있는 소프트웨어는 변하는 Trend에 재빠르게 진화할 수 있는 소프트웨어가 될 수 있다. 1. 복잡한 설계를 잘 나누는 데에 중점을 둔다. 2. DDD는 도메인 전문가와 소통을 중요하게 여긴다. 그래서 도메인이 무엇을 하고자 하는지에 명확해지기를 DDD가 유도한다.
  28. 28. TO BE CONTINUED 2탄 Bounded Context: 모델 무결성에 관하여
  29. 29. THANK YOU DDD 정복기 1탄 끝 @ jjo_ssoo

×