7. 도메인 주도
설계(DDD)에서는
이렇습니다.
프로젝트에 반영하기 위해서는
기술보다 도메인이 더 높은 우선순위
어떤 문제를 하기 위해서는 항상 도메인을 먼저
고민하는 것
그 도메인들을 바탕으로 설계(Design)
프로젝트에 지속적으로/반복적으로 반영하여
개발(Development)
7
10. DDD 도 하나의
패러다임
Ex) 애자일 개발 방법론 =
빠르게 소통하는 것을 통해 개발 항목들과 이슈들을
정리하고 해결
• 개발해야 할 항목이 줄어들지 않습니다.
• 기존의 이슈들을 해결하더라도, 프로젝트가
진행되면서 더 많은 이슈들이 발생합니다.
• 서로 간의 의견이 달라 논의가 길어지거나 자주
발생합니다.
• 고객이 기다려주지 않습니다.
• 기존의 이슈들의 우선순위가 자주 다음으로
미루어집니다.
10
11. DDD 의사 소통(Communication)의 한계
1. 연관된 요소가 많을 경우
대화 주제의 범위를 소규모에서 점진적으로 확대
2. 표현의 차이가 있을 경우
=> 서로 같은 의미로 말하고 있는지 다른 의미로 말하고 있는지?
=> 도메인 지식의 숙련도 차이
11
13. 기술 관점으로만은 한계가 있다.
13
객체지향 설계, MVC 등등
Database-Driven Design…
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. 가정을 해봅시다.
1. 하나의 소프트웨어를 개발
2. 모듈(module), 변수(variable),
함수(function) 등의 의존성을
완벽하게 최소화
3. 같은 팀의 모든 개발자들이
이해하고 공유할 수
있는 프로그래밍
스타일(programming style)도
지킴
15
16. 생각해볼 주제
• 구현 1년 후, 특정 기능에 버그가 발생했습니다. 어떤 1개의 기능에 대해 100개의
모듈이 존재한다면, 어떻게 찾아야 할까요?
• 내가 개발한 기능에서 다른 개발자가 새로운 동작을 추가해야 합니다. 기존에 이
기능과 관련된 100개의 동작이 있었습니다. 추가할 위치를 어떻게 찾고,
어떻게 추가해야 할까요?
• 내가 또는 다른 개발자가 개발한 기능을 수정하면서 side-effect가 발생하지 않을
것이라는 것을 무엇을 근거로 신뢰해야 할까요?
• 구현 1년 후, 각 요소들이 왜 그렇게 적용되었는지 어떻게 설명해야 할까요?
• 다른 개발자가 내가 개발한 기능과 함께 전체 로직을 설명해야할 상황이
발생하였습니다. 그 기능의 무엇 때문에 그렇게 구현하였는지 어떻게 설명해야
할까요?
16
24. Step4. Command 정의
각 Domain Event를 발생시키는 명령을 현재형으로 정의하며 명령형
=> 서술식을 개조식으로 바꾸면 됨
24
25. Step5. Trigger 정의
Command를 일으키는 Actor와 Event를 일으키는 External System와 Policy/Rule을 정의
Actor == 구체적인 사용자 유형
External System == 연계되는 외부 시스템
Policy/Rule == 이벤트와 관련된 정책이나 규정
25
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
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
