Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

도메인주도설계

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 51 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie 도메인주도설계 (20)

Anzeige

Aktuellste (20)

도메인주도설계

  1. 1. 도메인주도설계 Domain-Driven Design 2022.05.20 키트웍스 김천규 1
  2. 2. https://roadmap.sh/backend 2
  3. 3. 소프트웨 어란 무엇인가? 3
  4. 4. 소프트웨어 프로젝트의 목적은 사용자에게 가치 있는 소프트웨어를 개발하는 것입니다. 4
  5. 5. 실상은… 5
  6. 6. 6
  7. 7. 도메인 주도 설계(DDD)에서는 이렇습니다. 프로젝트에 반영하기 위해서는 기술보다 도메인이 더 높은 우선순위 어떤 문제를 하기 위해서는 항상 도메인을 먼저 고민하는 것 그 도메인들을 바탕으로 설계(Design) 프로젝트에 지속적으로/반복적으로 반영하여 개발(Development) 7
  8. 8. 도메인이란? 사용자가 사용하는 것들은 모두 도메인(Domain) == 업무의 집합 (업무 지식이자 요구사항) 8
  9. 9. 9
  10. 10. DDD 도 하나의 패러다임 Ex) 애자일 개발 방법론 = 빠르게 소통하는 것을 통해 개발 항목들과 이슈들을 정리하고 해결 • 개발해야 할 항목이 줄어들지 않습니다. • 기존의 이슈들을 해결하더라도, 프로젝트가 진행되면서 더 많은 이슈들이 발생합니다. • 서로 간의 의견이 달라 논의가 길어지거나 자주 발생합니다. • 고객이 기다려주지 않습니다. • 기존의 이슈들의 우선순위가 자주 다음으로 미루어집니다. 10
  11. 11. DDD 의사 소통(Communication)의 한계 1. 연관된 요소가 많을 경우 대화 주제의 범위를 소규모에서 점진적으로 확대 2. 표현의 차이가 있을 경우 => 서로 같은 의미로 말하고 있는지 다른 의미로 말하고 있는지? => 도메인 지식의 숙련도 차이 11
  12. 12. Why? 12 그럼에도 알아야하는 이유는?
  13. 13. 기술 관점으로만은 한계가 있다. 13 객체지향 설계, MVC 등등 Database-Driven Design…
  14. 14. SOLID SOLID는 객체 지향(Object-Oriented)에서 반드시 지켜야 할 5개의 원칙 • SRP(Single Responsibility Principle, 단일 책임 원칙) • OCP(Open-Closed Principle, 개방-폐쇄 원칙) • LSP(Liskov Substitution Principle, 리스코프 치환 법칙) • ISP(Interface Segregation Principle, 인터페이스 분리 원칙) • DIP(Dependency Inversion Principle, 의존성 역전 법칙) 14
  15. 15. 가정을 해봅시다. 1. 하나의 소프트웨어를 개발 2. 모듈(module), 변수(variable), 함수(function) 등의 의존성을 완벽하게 최소화 3. 같은 팀의 모든 개발자들이 이해하고 공유할 수 있는 프로그래밍 스타일(programming style)도 지킴 15
  16. 16. 생각해볼 주제 • 구현 1년 후, 특정 기능에 버그가 발생했습니다. 어떤 1개의 기능에 대해 100개의 모듈이 존재한다면, 어떻게 찾아야 할까요? • 내가 개발한 기능에서 다른 개발자가 새로운 동작을 추가해야 합니다. 기존에 이 기능과 관련된 100개의 동작이 있었습니다. 추가할 위치를 어떻게 찾고, 어떻게 추가해야 할까요? • 내가 또는 다른 개발자가 개발한 기능을 수정하면서 side-effect가 발생하지 않을 것이라는 것을 무엇을 근거로 신뢰해야 할까요? • 구현 1년 후, 각 요소들이 왜 그렇게 적용되었는지 어떻게 설명해야 할까요? • 다른 개발자가 내가 개발한 기능과 함께 전체 로직을 설명해야할 상황이 발생하였습니다. 그 기능의 무엇 때문에 그렇게 구현하였는지 어떻게 설명해야 할까요? 16
  17. 17. 이상적이여도 의구심이 생기는데? 17
  18. 18. 현실에서는? 18
  19. 19. 동작이 우선이다. 19
  20. 20. 도메인 주도 설계: 온라인 음식 주문 업무 20
  21. 21. Step1. Domain Event 정의 기능을 우선 모두 나열하는 단계 이벤트 21
  22. 22. Step2. Tell the story: 도출된 이벤트로 도메인의 업무 흐름을 이해하고 토론하여 보완 22
  23. 23. Step3. 프로세스로 그룹핑: 이벤트들을 프로세스로 그룹핑 프로 세스 23
  24. 24. Step4. Command 정의 각 Domain Event를 발생시키는 명령을 현재형으로 정의하며 명령형 => 서술식을 개조식으로 바꾸면 됨 24
  25. 25. Step5. Trigger 정의 Command를 일으키는 Actor와 Event를 일으키는 External System와 Policy/Rule을 정의 Actor == 구체적인 사용자 유형 External System == 연계되는 외부 시스템 Policy/Rule == 이벤트와 관련된 정책이나 규정 25
  26. 26. Step5. Trigger 정의 26
  27. 27. Step6. Aggregate 정의 Aggregate는 Entity와 VO의 집합 27
  28. 28. Step 7. Bounded Context정의 - "분홍색" 28
  29. 29. Solution Space: Context Map Shared Kernel: 복수의 Bounded Context가 공통으로 사용하는 Bounded Context간의 관계 Upstream-Downstream: Publisher(=Upstream)와 Subscriber(=Downstream) 관계 Bounded Context의 특성 종류 Open Host Service: 여러 종류의 Downstream Bounded Context를 고려하여 설계되는 Upstream Bounded Context Anti Corruption Layer: 다른 Bounded Context에서 받는 데이터를 본인에 맞게 구조, Type, 통신프로토콜 등을 변환해 주는 모듈계층을 가지는 Bounded Context. 보통 Downstream Bounded Context가 ACL을 가짐. 29
  30. 30. 도메인주도 설계와 아키텍처 • 계층형 아키텍처 • 헥사고날 아키텍처 • 클린 아키텍처 30
  31. 31. Layered Architecture Service Layer  Domain Layer와 Data Layer의 간의 제어, 연결  Biz logic을 layer에 구현 X Domain Layer => Domain Object별로 Business Logic처리를 담당 Data Layer Database와의 CRUD처리 Layer Spring boot, JPA에서는 Presentation Layer => @Controller, @RestController Service Layer, Domain Layer => @Service Data Layer => @Repository, @Entity 31
  32. 32. Transaction script vs Domain Model 32
  33. 33. DDD 관점으로 프로그래밍을 해보자 1. VO 2. Entity 3. Service 4. Repository 33
  34. 34. VO(값 객체) 1. 값의 불변성 2. 교환이 가능하다. 3. 등가성 비교 가능 원시 타입(number, string 등)만으로 표현할 수 없는게 있다. 금액 계산 예시 34
  35. 35. VO(값 객체) = Money 예시 35
  36. 36. 그냥 더하기, 빼기는 숫자로 하면 되는 거 아니야? 36
  37. 37. VO(값 객체) 금액끼리는 더하기, 빼기는 되지만 곱하기, 나누기는 불가 1000 + 2000 = 3000 1000 * 2000 = 2000000 ? 음수를 처리는 어떻게? 0으로만 표기, 차액으로 표기할지? 1000 – 2000 = -1000 1000 – 2000 = 0 원화/달러/엔화 등 통화가 다를 때는 고려를 어떻게? 37
  38. 38. VO(값 객체) = Money 예시 38
  39. 39. Entity(엔티티) 1. 가변이다 2. 속성이 같아도 구분할 수 있다 3. 동일성 사람을 예시로 39
  40. 40. 누군가를 식별할 수 있는 기준? 40
  41. 41. Entity 41
  42. 42. Entity와 VO 간 판단 기준? 엔티티에는 생애주기가 있다. 42
  43. 43. 엔티티는 시간에 따라 계속 변한다. 43
  44. 44. Service(서비스) 44 Entity나 VO에서 행하기 부자연스러운 로직을 정의 해놓는 곳 예시) 회원가입 기능 User 엔티티 회원이 스스로 등록하는 거는 이상
  45. 45. Repository(레파지토리) 도메인 객체를 저장하고 복원하는 퍼시스턴시 DB에 쓰고/읽기 기능만 (CRUD) 책임 45
  46. 46. DDD가 왜 필요할까? 46
  47. 47. 47
  48. 48. 48
  49. 49. 49
  50. 50. 감사합니다. 50
  51. 51. 출처 https://medium.com/@dreamingsandwich/도메인-주도-설계-domain- driven-design-in-real-project-1-도메인-83a5e31c5e45 https://happycloud-lee.tistory.com/94 https://helloworld.kurly.com/blog/road-to-ddd/ https://velog.io/@teo/Javascript에서도-SOLID-원칙이-통할까 참고도서 도메인 주도 설계 철저 입문 (코드와 패턴으로 밑바닥부터 이해하는 DDD) 51

×