박종복
669
2021-02-08 14:04:54 작성 2021-02-08 14:06:32 수정됨
1
739

DDD 아는 척 해보기


1. Domain

사용자가 소프트웨어를 통해서 해결하고자하는 문제영역으로 1개이상의 Sub Domain이 존재할 수 있다.

- 소프트웨어를 구현하고자하는 가장 큰 단위의 카테고리

예) 인사, 회계, 구매, 영업, 생산

2. Domain Model

Domain을 소프트웨어로 어떻게 해결할 것인지 각 구성요소를 개념적으로 표현한 것.

예) ERD, Class Diagram ...etc.

3. Ubiquitous language

Domain Model을 만들기 위해서 모호함이 없어야 하기때문에 SW전문가와 Domain 전문가 사이에 서로 용어를 이해할 수 있도록 정의한 용어 모음

- Domain 전문가가 사용하는 언어를 중심으로 정의한다.

- 단일 Bounded Context 내에서 정의되고 Bounded Context가 달라지면 용어가 뜻하는 의미가 달라질 수 있다.

- Ubiquitous lanaguage를 우리말로 직역하면 "보편적 언어", 나에게 설명하라고 한다면 "동일맥락안에서 가장 빠르게 커뮤니케이션 할 수있는 용어"

- "짭새"라는 단어는 한때는 뒷골목에서 통용되는 Ubiquitous language 였다.

4. Bounded Context

- 피자 한조각이 식탁위에 올려져 있으면 음식 이지만, 도로변에 놓여져 있다면 쓰레기가 된다.

-> 식탁위, 도로변은 Bounded Context 음식, 쓰레기는 Ubiqoutus language로 식별될 수 있다.

- 영업부서에서 상품은 판매해야할 대상이지만, 구매부서에서 상품은 구매해야할 대상이다.

-> 동일한 단어지만 Bounded Context가 달라지면 전혀 다른 비지니스 대상으로 취급된다.

- 사랑이란 단어는 가족간, 남녀간에 다른 의미로 해석된다. 동성 친구간에는 "싸대기 맞을일?"

- Context를 나누지 않았을때 우리는 "판매상품", "구매상품"이라는 수식어를 계속 덪붙이게 되고 도메인영역에서 사용하는 언어와 달라지게 되면서 의사소통이 어려워 지게된다.

- 이렇게 Ubiqoutus language가 통용될 수 있는 범위를 Bounded Context(제한된 맥락)

- Bounded Context는 잘 조직된 조직의 구조와 유사하게 식별될 수 있다.

- 일반적으로 커뮤니케이션 능력이 뛰어난 사람은 맥락(Context)을 잘 구분하는 사람을 말하고 그렇지 않은 사람을 우리는 "맥락없다"라고 표현할 수 있다.

5. Context Map

Bounded Context간에 공유되는 Domain Model로서 서로다른 Bounded Context간에 의사소통 관계 또는 공유하는 Domain Model

- 각 Bounded Context의 관심사에 따라 부분적으로 매핑될 수 있다.

- 각 Bounded Context는 그들의 관심사에 대해서만 관리하므로 모델은 단순하고 이해하기 쉽게 작성된다.

- 위 그림은 Banking Domain에서 Banking, Payment 2개의 Bounded Context가 식별되었을때 두 Context간 Account의 Context Map관계를 표현한다.

- Banking Context는 잔고와 계좌번호만 관심이 있고, Payment는 계좌번호만 관심이 있다.

- 위와 같이 종적 관심사 뿐아니라 횡적 관심사에 따라 Payment Context는 체크카드 신청한 계정만 관리할 수도 있다.

- 결국 Domain Model 중복이 발생하고 데이타 일관성과 무결성이 깨질 가능성이 존재하지만 Bounded Context간 결합도를 낮출 수 있다.

6. Aggregate

- 일관성을 유지해야될 Entity들을 묶어 놓은 것으로 1개의 Root Entity를 가지고 Root Entity만을 통해서 외부에서 접근 할 수 있다.(캡슐화)

- 1개이상의 Entity와 Value Object로 구성됨

- ERD로 표현한다면 PK를 가진 주 Entity와 보조 Entity의 집합

- 외부에서 Aggregate 내부의 상세에 접근하지 않도록 해서 소프트웨어 결합도를 낮춘다.


7. 결론

제목에서 언급했듯이 위 내용은 DDD에 대해서 깊이 있는 내용은 아닙니다.

사실 저도 더 깊이있는 내용은 잘 모릅니다.;;

하지만 DDD를 어떻게 접근할지 대충 감은 잡을 수 있지 않을까요?

0
  • 댓글 1

  • GSGfactory
    370
    2021-02-15 00:47:06 작성 2021-02-15 00:47:50 수정됨

    결국은 DDD는

    누가 : Domain전문가와 System Programmer가

    왜 : 설계만으로 이미 대부분의 개발이 끝나는 개발을 위해

    무엇을 : Domain에 기반한 System의 설계를 

    어떻게 : Domain의 모든 것을 담을 수 있는 통합적 해석을 통해 만든다.

    라는 개념이고 그 "어떻게"는 아직 정립이 완성되지 못한 설계법입니다.

    모두가 잘 이해할 수 없는 이유는 모두가 이해할만큼 정립되지 않았기 때문입니다.

  • 로그인을 하시면 댓글을 등록할 수 있습니다.