도메인 주도 설계(DDD로 약칭)는 비즈니스 요구 사항에 의해 먼저 알려진 소프트웨어 설계 및 개발에 대한 접근 방식이다. 프로그램의 구성 요소(Object, Class, 배열 등)는 비즈니스가 운영되는 산업, 부문 또는 도메인을 나타낸다.
DDD는 도메인 전문가들이 입력한 도메인 입력에 따라 소프트웨어를 생성하는 소프트웨어 설계 방법이다. 도메인이란 제안된 소프트웨어가 해결하려는 문제의 특성을 말한다.
이는 소프트웨어가 문제의 특성에 따라 특별히 설계되어 문제를 해결하도록 한다는 것을 의미한다. 이를 달성하기 위해서는 사용되는 소프트웨어 코드의 구조와 언어가 비즈니스 도메인과 일치해야 한다. 이 방법은 또한 비즈니스 현실과 소프트웨어 코드 사이의 격차를 좁히기 위해 다양한 원칙과 패턴을 사용한다. 도메인 주도 설계는 프로젝트의 주요 초점을 핵심 도메인으로 유지하면서 도메인 복잡성을 해결하는 데 가장 도움이 된다.
복잡한 시스템과 관련된 문제 중 하나는 비효율적인 의사소통입이다. 그러나 모든 팀 구성원들은 도메인 모델과 관련된 보편적 언어를 통해 서로 효율적으로 의사소통할 수 있고 보편적 언어는 덜 기술적인 전문 용어를 제거하는 더 단순한 용어로 구성되어진다.
도메인 주도 설계는 객체 지향 분석 및 설계에 기반한 구조적 시스템이다. 이는 시스템이 객체와 함께 작동하며 조작, 개선 또는 해체될 수 있음을 의미한다. 개발자는 전체 시스템을 변경하거나 구성 요소를 개별적으로 조정할 수 있다.
도메인 주도 설계는 도메인 전문가들이 제공/조언한 도메인의 아이디어에 기반한 인터페이스를 구축하는 개념이다. 이는 DDD가 사용되는 모든 애플리케이션이 그 속성에 따라 도메인에 완벽하게 적합하도록 보장한다. 이는 도메인의 속성과의 조화를 강조하기 전에 UI/UX의 필요성을 강조하는 다른 애플리케이션들에 비해 이점이다.
설계 과정에서 위에서 설명한 것처럼 사용자 경험보다 도메인 조화를 먼저 고려해야 한다. 이는 회사가 사용자 목표를 달성하도록 보장하는 등의 다른 이점을 낳는다. 도메인이 설계 과정에서 중심이 되면 사용자의 요구를 만족시킬 좋은 제품을 제공하기 때문에 사용자는 이를 달성할 수 있다.
도메인 주도 설계를 사용하고 도메인 전문가와 협력함으로써 효율적이고 효과적인 제품을 얻는 것은 불가피하다. 도메인의 전체 세부 사항을 알지 못할 수 있는 개발자들만 작업하는 것과 달리, 도메인 전문가들은 필요한 기능을 갖춘 제품을 만들어 비즈니스 운영 방식을 쉽게 나타낼 수 있다.
도메인 주도 설계 팀에 주제에 대해 내외부를 모두 아는 도메인 전문가가 최소한 한 명 없다면 프로젝트는 처음부터 실패할 가능성이 높다. 팀은 도메인에 대한 지식이 풍부한 외부 인력을 고용해야 한다. 이 개인은 개발 주기 전반에 걸쳐 다양한 조언을 제공하며 팀의 도메인 전문가로 활동할 것이다. 이는 노력이 낭비되는 것을 방지하기 위해 필요하다.
대부분의 경우 팀은 표준 프로젝트를 만들기 위해 여러 활동을 반복적으로 수행해야 하며, 이는 미래에 필요한 형태로 변경할 수 있다. 이는 일부 조직에게는 좋은 일일 수 있지만 다른 조직에게는 상당한 단점일 수 있다. 이는 특히 과거에 성장에 유연하지 않은 모델을 사용했던 조직에게 해당된다. 이러한 모델의 예로는 워터폴 모델이 있다.
도메인 주도 설계가 도메인 복잡성을 해결하는 데 적합하지만, 프로젝트에 도메인 복잡성이 적고 기술적 복잡성이 높은 경우 좋은 결정이 아닐 수 있다. 이는 기술적인 문제가 도메인 전문가가 이해하기에는 너무 많아서 나중에 문제를 일으킬 수 있기 때문다.
이 설계는 일관된 의사소통과 다양한 활동의 반복적인 구현이 필요하기 때문에 구현하는 데 많은 시간이 소요된다. 또한, 잘못될 가능성이 매우 높다. 잘못된 단계를 반복하면 활동의 악순환을 일으키고 나쁜 결과를 초래할 수 있다.