이 문서는 Google Cloud Translation API를 사용해 자동 번역되었습니다.
어떤 문서는 원문을 읽는게 나을 수도 있습니다.
DDD(Domain-Driven Design)는 구현보다는 도메인 또는 문제 공간에 초점을 맞춘 소프트웨어 개발 접근 방식입니다. 도메인 지식의 중요성을 강조하고 도메인을 정확하게 반영하는 모델을 구축해야 할 필요성을 강조합니다.
DDD(Domain-Driven Design)는 도메인 지식의 중요성을 강조하는 소프트웨어 개발 접근 방식입니다. 에릭 에반스(Eric Evans)가 그의 저서 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 처음 소개했습니다.
DDD의 목표는 도메인을 정확하게 반영하는 모델을 구축하는 것입니다. 이를 위해 DDD는 도메인을 이해하고 도메인을 정확하게 반영하는 유비쿼터스 언어를 만들고 도메인을 정확하게 반영하는 모델을 만들어야 할 필요성을 강조합니다.
DDD는 다음 원칙을 기반으로 합니다.
Domain-Driven Design은 Eric Evans가 그의 저서 Domain-Driven Design: Tacking Complexity in the Heart of Software에서 처음 소개했습니다. 이 책은 2003년에 출판되었으며 이후 소프트웨어 개발에 널리 채택된 접근 방식이 되었습니다.
Domain-Driven Design의 주요 기능은 다음과 같습니다.
예를 들어 고객 주문을 관리하는 데 사용되는 소프트웨어 시스템을 생각해 보십시오. 이 시스템에서 도메인에는 고객, 주문, 제품 및 지불 방법이 포함됩니다.
DDD를 사용하면 도메인이 고객 관리, 주문 관리, 제품 관리 및 결제 관리와 같은 별개의 컨텍스트로 나뉩니다. 각 컨텍스트에는 자체 언어와 모델이 있으며 모델은 도메인을 정확하게 반영하도록 설계됩니다.
도메인 기반 설계의 주요 이점은 다음과 같습니다.
도메인 주도 설계의 주요 단점은 다음과 같습니다.
Domain-Driven Design은 Object-Oriented Design, Test-Driven Development 및 Agile Development와 같은 소프트웨어 개발에 대한 다른 접근 방식과 관련이 있습니다.
도메인 주도 설계는 종종 객체 지향 설계, 테스트 주도 개발 및 애자일 개발과 같은 소프트웨어 개발에 대한 다른 접근 방식과 함께 사용됩니다.
Domain-Driven Design은 개체 관계 매퍼, 종속성 주입 프레임워크 및 자동화된 테스트 프레임워크와 같은 다른 도구 및 기술과 함께 자주 사용됩니다.