도메인 중심 설계의 기본 원칙

자기소개



풀 스택 엔지니어의 k-okina입니다.
최근 DDD를 학습하고 있습니다만, 비즈니스 전문가인 사람에게 Eric Evans씨의 DDD의 비디오를 보여주면 매우 알기 쉽게 해설해 주고 감격했으므로 공유합니다.

도메인 중심 설계 정의



Eric Evans는 DDD는 다음 4가지 원칙으로 구성되어 있다고 설명합니다.
그 설명을 소프트웨어 전문가가 이해하기 쉽도록 번역합니다.

1. Focus on the core complexity and opportunity in the domain



번역 : 복잡하고 해결할 때 이익이있는 문제의 초점에 집중합니다. (문제의 핵심)

2. Explore models in a collaboration of domain experts and software experts



번역 : 관련 전문가와 협력하여 문제에 접근하는 모델(구조)을 만든다.

3. Write software that expresses those models explicitly



번역: 모델들을 잘 표현한 소프트를 만든다

4. Speak ubiquitous language within a bounded context



번역 : 경계가있는 컨텍스트에서 공통 언어로 말하기

보충



예 1. 이것이 무슨 의미인가 하면, 예를 들면, 피카츄라고 하면 피카츄라고 인식합니다. 그것은 서로 공통된 포켓몬 컨텍스트가 있기 때문입니다.
그러나 포켓몬을 모른다 == 피카츄는 아무것도 의미하지 않는다 == 공통 컨텍스트가 아니다
만약 상대가 포켓몬을 알고 있다는 전제로 피카츄라고 말해 버려 포켓몬을 모르는 경우는 미스 커뮤니케이션=오해가 발생해, 응? ? ? ? 됩니다.
그것을 인식하는 것은 매우 중요합니다.

예 2.



전제: X그리고이 전제가 없었다면, Y-X는 +/- 어느 것입니까?
Eric Evans는 이 전제를 제한이라고 합니다.
요점은 전제가 단어의 의미를 제한한다는 것입니다.
그것이 도메인에서 경계를 결정하는 것처럼.

예 3.



포켓몬이라는 전제가 피카츄의 하나의 의미를 만들고 있다.
다른 나라에서는 피카츄는 그 피카츄가 아닐지도 모른다.
그 피카츄가 피카츄라는 도메인의 영역이 컨텍스트에 의해 정의됩니다.
이 경우 경계 = 전제 = 컨텍스트
영역 = 도메인
전제를 인식하지 못함 = 도메인 어긋남, 프로젝트 어긋남
즉, 피카츄가 피카츄라고 의미하는 영역이 도메인이고, 그 도메인이 유효한 것은 그 문맥내이면
포켓몬을 아는 사람의 집단이 있고, 그것은 추상적으로 도메인을 구성합니다.

예 4.




이것은 일본의 도메인
이 중에서 말하는 말은 이 밖에서는 통하지 않습니다.
전제==일본어==컨텍스트
일본어를 아는지 모르는지로 컨텍스트는 경계가 되어 있습니다
그러나 오키나와 밸브는 일본 지역 내이지만 오키나와에서만 통합니다.
거기에 도메인이 있습니다.
그러나 공통 컨텍스트가 있기 때문에 오키나와 사람과 오사카 사람이 함께 문제 해결을 시도하면 도쿄 벤치에서 대화합니다.
이것이 Eric Evans의 말
경계가 붙은 컨텍스트에서 공통 언어로 말하는 것입니다.

즉 컨텍스트란?



예 4에서 설명한 것처럼 오사카 사람과 오키나와 사람의 두 도메인이 하나의 컨텍스트 내에 있었던 것처럼 컨텍스트는 도메인 범위를 결정합니다.
굉장히 간단하게 말하면, 컨텍스트는 환경(일본)으로, 도메인은 그 환경내의 특정 영역(오사카·오키나와 등)의 일입니다

마지막으로



어땠습니까?
보다 심플하게 설명·보충·추기할 수 있는 분 있으시면, 편집 리퀘스트 어째서 부탁드립니다!

좋은 웹페이지 즐겨찾기