[방법론] 도메인 주도 설계(DDD)
도메인 주도 설계(Domain Driven Design)
1.도메인
- 자동화된 비즈니스나 현실 세계의 문제이다.
- 해결하고자 하는 문제 영역이라고 볼 수 있다.
2.도메인 주도 설계
-
소프트웨어 설계 기법의 하나이다.
-
소프트웨어과 도메인 사이
-
문제점
<그림 출처 : https://cskstory.tistory.com/search/ddd>
모델이 세분화 되면서 본질이 흐려지게 되고, 결국엔 도메인과 소프트웨어 사이를 멀게한다.
-
모델이 그 가치를 잃지 않고 소프트웨어 개발에 기여하도록 도메인을 잘 표현한 모델을 만들고 바라보는 것이다.
3.DDD를 하기 위한 2가지 준비물
-
Ubiquitous Language
도메인 전문가와 원활하고 지속적인 대화가 필요하며 모든 사람이 모델에 나타나 있는 같은 용어를 사용해야 한다. 해당 도메인의 핵심만 표현되어야 한다.
-
Model Design Driven
중요한 모델이 생명력을 잃지 않고 지속적으로 관리되고, 도메인의 본질을 잃지 않게 하기 위해 유지하는 것이 Model Design Driven이다. 모델이 생명력을 잃지 않기 위해 몇가지 패턴들이 쓰인다.
4.패턴
모델 주도 설계를 위해서는 위와 같이 패턴을 적용하는 것을 권장한다. 그러나 영어라서 이해가 어려울 수 있으니 아래를 보자.
<그림 출처 : https://zetawiki.com/wiki/도메인_주도_설계_DDD>
<그림출처 : https://www.slideshare.net/gyumee/ddd-10067384>
-
계층구조(Layered Architecture)
-
엔티티(Entity)
고유의 식별자를 갖는 객체로 자신의 라이프사이클을 갖는다.
-
값객체(Value Object)
식별자가 없으며 영속성이 필요없는 객체이다.
수정할 수 없고 필요한만큼 복제해 전달하여 사용한다.
-
서비스(Service)
특정 Entity나 Value Object에 속할 수 없는 도메인의 개념 표현이다.
주로 여러 객체에 걸쳐서 일어나는 행위를 담당한다.
상태 정보를 관리하지 않는다.
-
집합(Aggregate)
Entity와 Value를 개념적으로 하나로 묶은 것이다.
데이터를 변경할 때 하나의 단위로 간주되는 관련된 객체들의 집합니다.
외부에서 접근할 수 있는 단하나의 창구인 root를 가진다.
-
팩토리(Factory)
복잡한 객체 생성의 절차를 캡슐화 한것이다.
단순한 경우라면 생성자를 사용한다.
-
레파지토리(Repository)
객체의 저장을 담당한다.
이미 존재하는 도메인 객체의 참조를 얻는 로직을 캡슐화 한것이다.
5.도메인 모델 관리
-
모듈
결합도는 낮고 응집도는 높게한다.
-
리팩토링
코드 리팩토링 뿐 아니라, 모델 리팩토링도 중요하다.
분명하지 못한 설계영역을 다시 살펴본다.
지나치게 비대한 객체를 의심해본다.
출처
블로그
https://cskstory.tistory.com/search/ddd
https://zetawiki.com/wiki/도메인_주도_설계_DDD
https://hyper-cube.io/2017/05/11/DDD_%EC%9D%B4%EC%95%BC%EA%B8%B0_part1/
슬라이드쉐어
https://www.slideshare.net/gyumee/ddd-10067384
https://www.slideshare.net/madvirus/ddd-final
