DDD~ DDD~
DDD(Domain Driven Design)
도메인 주도 설계
: 각각의 기능적인 문제 영역들을 도메인이라고 정의하고, 그렇게 정의된 도메인에 대한 로직을 중심으로 설계하는 것
DDD 특징
- 데이터 중심이 아닌 도메인의 모델과 로직에 집중
- 동일한 표현과 단어로 구성된 단일화된 언어체계의 사용
- Software Entity와 Domain간 개념을 일치하여, 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델 지향
DDD 구성 요소
- 바운디드 컨텍스트: 범위를 구분해 놓은 하위 도메인 개념
- 애그리거트: 데이터 변경 단위, 라이프 사이클이 같은 도메인을 모아놓은 집합
-> 쉽게 말하자면 비슷한 범주의 연관된 업무들을 하나로 그룹화한 것 - 애그리거트 루트: 하나의 애그리거트를 대표하는 도메인
- 컨텍스트 맵: 바운디드 컨텍스트간의 관계를 보여주는 맵
DDD 4계층
- Presentaion:사용자의 요청을 받고, 응답을 반환하는 역할 -> Controller, Dto
- Application: 비즈니스 흐름을 조정하는 역할 -> Service
- Domain: DDD의 핵심 계층으로, 비즈니스 로직이 포함되는 영역 -> Entity, Repository Interface, VO
- InfraStructure: 기술적 세부 사항을 담당하는 계층 -> Repository Impl, API Client
DDD를 사용하는 이유?
비즈니스 로직을 중심으로 소프트웨어를 설계하여 유지보수성과 확장성을 높이기 위해!
일단 내가 이해한 바로는 이 정도이다. 어려운 내용이어서 제대로 이해한 건지도 잘 모르겠다..
개발은 다듬어도 다듬어도 끝이 없다는 것을 느꼈다. 세상에 좋은 코드는 많고 내 코드는 너무 하찮군...
New기술들을 많이 배워간다. 내일은 지금까지 한 프로젝트를 DDD 구조로 변경해보는 것을 시도할 예정이다!!
딴소리지만 D를 많이 보다보니 대학교 시절 D를 받고 깜짝 놀랬었던 기억이 난다... 지금 보니 추억이다(?)
빠이
