정보 기술이 발전하고 새로운 소프트웨어가 개발됨에 따라 기업은 모든 조건을 포괄하고 테스트 및 개발이 용이한 보안 응용 프로그램 및 시스템을 비교적 신속하게 생성할 수 있는 방법을 점점 더 많이 찾고 있습니다. 시행 착오를 통해 많은 조직에서 소프트웨어를 구축하는 이상적인 방법으로 간주하는 접근 방식이 만들어졌습니다.
도메인 주도 설계에 관한 것입니다. 회사의 소프트웨어 개발에 대한 이 접근 방식은 정확히 무엇입니까?
도메인 주도 설계(약칭 DDD) – 이 접근 방식이란 무엇입니까?
처음에는 DDD 접근 방식이 정확히 무엇인지 정의할 가치가 있습니다. 기본적으로 비즈니스의 요구 사항을 반영해야 하는 응용 프로그램 및 시스템을 구축하는 방법입니다. 동시에 소프트웨어에 포함된 전제 조건이 되는 비즈니스 가정입니다.
DDD 방법을 뒷받침하는 입력은 무엇입니까? 우선, 모든 소프트웨어의 설계는 프로그래머와 동시에 솔루션의 대상 소비자인 비즈니스와 직접 관련된 사람들 간의 동등한 협력을 기반으로 해야 합니다. DDD 방식으로 시스템을 구축하기 위한 두 번째 조건은 도메인 형태의 프로젝트 로직을 설계하는 것이다.
도메인이란 무엇입니까? 간단히 말해서 이것은 구현해야 하는 특정 비즈니스 영역입니다. 새로 만들거나 개발한 소프트웨어로 개선해야 할 부분. 특정 개념과 기능의 중요성과 본질에 따라 도메인을 다음과 같이 나눌 수 있습니다.
- 시스템에서 가장 중요한 부분이며 가장 중요한 기능을 담당하는 주요 도메인입니다.
- 주 도메인의 확장인 지원 도메인 – 없으면 지원 도메인은 의미가 없습니다.
- 중요하지만 선택적인 기능인 공통 도메인
DDD는 무엇으로 구성되어 있습니까?
Domain Driven Design의 원칙을 기반으로 새로운 소프트웨어를 만드는 프로세스는 역학, 데이터 입력 및 출력, 서버와의 통신, 데이터베이스 처리와 관련된 많은 기술적 문제를 포함하는 소프트웨어 개발에 대한 기존 접근 방식과 다소 다릅니다. 조직에서 사용하는 다른 도구와의 통합.
DDD 프로그래밍은 주로 소프트웨어에 포함되어야 하는 비즈니스 매개변수의 매우 기본적인 구현을 포함하는 도메인 모델(루트, 하위 및 일반 도메인)로 구성됩니다. 코드 개발을 담당하는 프로그래머가 새 소프트웨어를 만드는 목적을 완전히 이해하고 도메인이 지닌 가치를 이해하는 것이 매우 중요합니다. DDD는 도메인 전문가와 프로그래머가 해당 언어를 쉽게 이해할 수 있도록 하는 언어를 정의하지 않고는 할 수 없습니다. 이 접근 방식을 위해 이 언어를 유비쿼터스 언어라고 했습니다.
도메인 주도 설계 접근 방식을 사용할 때 어떤 어려움이 발생할 수 있습니까?
DDD 방식을 사용할 때 가장 큰 문제는 무엇입니까? 첫째, 비즈니스와 기술적인 측면 간의 커뮤니케이션입니다. 일반적으로 DDD 접근 방식에는 접근 방식에 대한 깊이 있는 지식을 갖고 있고 스스로 비즈니스 및 IT 커뮤니케이션에서 “컴파일러” 역할을 할 도메인 전문가를 위한 공간이 항상 있어야 합니다.
DDD 방식으로 생성된 프로젝트의 비율이 상대적으로 적기 때문에 이러한 역할을 온전히 헌신적으로 수행할 수 있는 사람을 찾기가 매우 어렵습니다. DDD 방법론을 사용하여 생성하는 프로그래머의 경험 부족도 추가 어려움을 유발할 수 있습니다.
DDD 방식의 장점과 단점
새 소프트웨어를 만들 때 도메인 기반 설계 접근 방식을 사용하는 것의 이점부터 시작하겠습니다. 우선, 기능, 구현 목표 및 다양한 수준의 수가 너무 많아 기존 응용 프로그램 디자인에서 개념적으로 캡처하기 어려운 복잡한 프로젝트에 대한 훌륭한 솔루션입니다. DDD 접근 방식은 비즈니스의 실제 요구 사항을 충족합니다. 절반 정도의 여유가 없습니다. 프로그래머가 도메인을 올바르게 해석하면 최종 사용자의 요구 사항에 따라 완전히 구현됩니다. 또한 초기부터 DDD 접근 방식에 따라 생성된 애플리케이션 개발 비용이 상대적으로 저렴하다는 점도 주목할 가치가 있습니다.
이 기술을 사용할 때의 단점은 무엇입니까? 주요 단점은 새로운 소프트웨어를 개발하는 이러한 방식을 사용하는 연습이 거의 없다는 것입니다. 이 때문에 프로젝트 팀의 관점에서 새로운 전략을 사용하기 시작하면 개념에 대한 완전한 오해와 결과적으로 실패의 위험이 있습니다.
DDD 방법론을 사용하여 애플리케이션을 설계하고 구축하는 초기 생산 비용은 더 높으며, 이는 확실히 이러한 방식으로 구현되는 소수의 프로젝트에 영향을 미칩니다.
내 프로젝트에서 DDD를 어떻게 사용하나요?
우리 프로젝트에서 DDD를 실용적으로 사용하려면 실제로 처음부터 시작해야 합니다. 모델의 나머지 부분이 전통적인 방식으로 설계되는 도메인 주도 설계 개념을 부분적으로 채택하는 것은 불가능합니다. 이 경우 최종 제품에 대한 만족도는 IT 팀과 최종 사용자 모두에서 낮습니다.
