DDD (도메인 주도 설계)

소프트웨어는 현실 세계의 프로세스를 자동화하거나 비즈니스 문제를 해결하기 위해 개발된다. 

자동화된 비즈니스 프로세스나 현실 세계의 문제가 바로 소프트웨어 도메인이다.

소프트웨어는 도메인으로부터 시작되고 떼려야 뗄 수 없는 관계를 가지고 있음을 이해해야 한다.

소프트웨어 프로젝트를 시작할 때 우리는 그 소프트웨어가 동작해야 하는 도메인에 집중해야 한다.

소프트웨어의 전반적인 목적은 특정 도메인의 일이 더 잘 굴러가도록 하는 데 있기 때문이다.

따라서 소프트웨어는 도메인을 모델링해야 한다.

DDD는 도메인의 가치를 최우선시하는 모델링 기법이라 볼 수 있다. 

도메인 주도 설계는 설계와 개발 방식을 연관 지어, 설계와 개발이 더 나은 해결책을 도출하는 데 어떻게 함께 작동할 수 있는지 보여준다.

1. 좋은 설계는 개발을 가속화하고

2. 동시에 개발 프로세스에서 받는 피드백이 설계를 더욱 강화한다.

DDD는 소프트웨어 전문가와 도메인 전문가 사이의 의사소통의 장벽을 허무는것에서 시작한다.

개발자는 클래스, 메서드, 알고리즘, 패턴 등으로 마음속이 가득차 있고 늘 현실 세계를 프로그램으로 매핑하려는 경향을 지닌다.

개발자는 객체지향 프로그래밍 관점에서 상속, 다형성 등을 생각하고 항상 그런 식으로 말하기를 좋아한다.

그러나 도메인 전문가는 보통 이러한 개념들에 대해 생소하다. 자신의 특화된 분야에 대해서만 알 뿐이다.

그리고 이러한 것들을 외부인들이 이해하기 어려운 자신들만의 전문용어로 이야기한다.

이러한 의사소통 방식의 차이를 극복하려면 우리는 모델을 만들 때,

1. 모델에 대한 아이디어

2. 포함되어야 할 요소

3. 그것들을 어떻게 연결할 것인지

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

4. 어떤 것들이 관계가 있고 어떤 것들은 관계가 없는지

와 같은 정보를 교환해야만 한다.

이 수준에서 이루어지는 의사소통이 프로젝트가 성공하는 데 가장 중요하다.

따라서 우리는 모델을 이야기하고 정의할 때 같은 언어로 말할 필요가 있다.

도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것에 있다.

모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문에 모델 기반 언어를 사용하는 것이 적절하다.

이러한 관점에서 이 언어를 DDD에서는 유비쿼터스 언어라 부른다.

DDD에서는 설계 단계에서 도출된 원본 모델이 최종 구현까지 그대로 이어지기를 소망한다.

일반적인 분석 모델은 도메인을 이해하기 위해서만 사용된다. 분석 모델은 설계 원리들을 염두에 두고 만들어진 것이 아니기 때문에

분석 모델을 가지고 설계 작업을 수행하기란 쉽지 않다. 개발자들은 분석 모델에 적응하거나 아니면 모델과 별개의 설계를 하게 된다.

그러면 모델과 코드 사이에는 더 이상 매핑 관계가 존재하지 않게 되며 분석 모델은 코딩이 시작되자마자 곧바로 폐기되고 만다.

이것이 무엇을 의미하냐 하면 도메인에 대한 분석가들의 지식이 일부 사라질 수 있다는 의미이다.

DDD는 개발자들이 분석가들의 회의에 함께 참여하고, 코드를 설계하기 전에 도메인과 모델을 명확하고도 완전하게 이해하기를

권고한다. 도메인 모델링과 설계를 밀접하게 관련시키는 것이다. 모델이란 소프트웨어 그 자체와 설계 고려 사항에 초점을 맞추어

만들어져야 하며, 개발자들은 모델링 프로세스가 진행되는 동안 함께 참여해야 한다.

여기서 중요한 점은 설계 작업이 직관적이면서 모델을 기반으로 수해되도록 소프트웨어로 정확하게 표현할 수 있는 모델을 선택하자는 것이다.

코드와 기반이 되는 모델을 밀접하게 연관시킴으로써 코드에 의미가 생기고 모델은 실제적으로 중요한 가치를 지니게 된다.

DDD는 기본적으로 사용자들이 밀접하게 관계되어 있는 도메인 이슈에 집중해야 한다는 원칙에 기반을 둔다.

도메인이란 우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분이고, 전문가들에게는 개념적 형태로 표현해 내기 위해 힘써서 협동해야 할 대상이다.