UML은 매우 복잡하고 많은 개념 용어가 포함되어 있기 때문에 배우기가 어렵습니다. 도메인 모델은 그 중 하나이며, 인터넷에서 검색할 때 도메인 모델에 대한 지식은 두 가지가 있어야 하는데, 하나는 원래의 전통적인 소프트웨어 개발 프로세스에서 파생된 것이고, 다른 하나는 도메인 중심 설계(DDD)에서 파생된 것입니다. 매우 혼란스럽습니다. 다음은 도메인 모델의 개념에 대한 나의 이해 중 일부입니다.
이론학파
도메인 모델은 분석 범위가 업계 전체이며, 업계 내 비즈니스의 고유하고 고유한 규칙성을 추상화한 특별한 비즈니스 모델입니다. 비즈니스 모델은 더 추상적입니다. 소프트웨어 개발의 범위에 속하지 않으며 소프트웨어 개발과 관련이 없는 개념입니다.
실학
도메인 모델은 소프트웨어 개발 프로세스의 분석 단계에서 시스템의 기능적 요구 사항을 충족하는 방법을 분석하는 데 사용되는 모델입니다. 소프트웨어 개발 범주에 속하며 주로 UML 클래스 다이어그램에서 도메인 모델을 설명하는 데 사용됩니다.
비즈니스 모델은 비즈니스 모델링의 결과물입니다. 비즈니스 모델링 연구의 대상은 회사 또는 조직입니다. 비즈니스 모델링은 소프트웨어 개발 프로세스의 초기 단계에 속합니다.
소프트웨어 개발 프로세스: 비즈니스 모델링, 요구 사항, 분석 및 설계.
소프트웨어 개발 과정에서 우리가 접하게 되는 도메인 모델은 실기학파에 속합니다.
이론 학교
도메인 모델은 특별한 비즈니스 모델이며 그 기능은 다음과 같습니다.
실천 학교
도메인 모델 기능: < /p>
비즈니스 모델의 역할:
이론파
도메인 모델은 특별한 비즈니스 모델이므로 비즈니스 모델의 모든 특성을 갖고 있지만 도메인 모델보다 더 추상적입니다. 비즈니스 모델, 더 일반적입니다.
실용학교
소프트웨어 개발 과정 중 비즈니스 모델링 단계에서 비즈니스 모델이 생성되고, 분석 단계에서 도메인 모델이 생성된다.
비즈니스 모델은 고객 회사의 비즈니스를 이해하는 시스템 요구 사항 담당자의 산물입니다. 요구 사항의 다음 단계에서는 비즈니스 모델을 시스템 요구 사항을 얻기 위한 입력으로 사용합니다.
도메인 모델은 시스템의 기능적 요구 사항을 충족하는 방법을 분석하는 시스템 분석가의 산물입니다. 디자인의 다음 단계에서는 도메인 모델을 입력으로 사용합니다.
'실용학교'가 그 예를 든다.
프로젝트를 받으면 먼저 호텔 예약 시스템 구축이 필요하며, 먼저 비즈니스 모델링을 실시하고 호텔 경영 관련 업무를 이해해야 한다. 이때 비즈니스 모델에는 호텔 예약 비즈니스 링크 외에도 호텔 예약과 동일한 수준의 다른 비즈니스 링크도 포함됩니다.
다음으로 호텔 예약에 중점을 두고 호텔 예약 시스템 요구 사항, 즉 시스템 사용 사례 및 요구 사항 사양을 얻기 위한 기존 프로세스를 개선하겠습니다.
다음으로 시스템 사용 사례와 요구 사항 사양을 분석하여 호텔 관리 시스템의 기능적 요구 사항을 충족하는 방법을 분석하여 도메인 모델을 얻습니다.
'이론학파'와 '실천학파'의 도메인 모델은 서로 다른 범주입니다. 이를 구별하지 못하면 이해에 혼란이 생길 수밖에 없습니다.
Eric Evans의 "도메인 중심 설계" 또는 "도메인 중심 설계"에서 유래한 "도메인 모델"도 있습니다. DDD는 포괄적인 소프트웨어 시스템 분석 및 집합입니다. 설계 측면에서 개체 모델링 방법을 사용하므로 이 두 도메인 모델을 명확하게 구분할 수 있습니다. 혈액 손실 모델, 빈혈 모델, 혼잡 모델과 같은 개념은 모두 DDD 범주의 "도메인 모델"에 속합니다.
1. 해결해야 할 핵심 문제가 다릅니다
위에서 언급한 것처럼 도메인 모델은 비즈니스를 분석하는 데 사용되는 분석 모델입니다. 실제 프로젝트에서 해결해야 할 핵심 문제는 다음과 같습니다. :
"도메인 모델"은 포괄적인 분석 및 설계 모델입니다. 해결해야 할 핵심 문제는 다음과 같습니다.
전통적인 소프트웨어 개발 프로세스에서는 분석(시스템 요구 사항 분석)이 수행됩니다. 그리고 디자인(시스템 설계)은 "시스템 분석가"와 "시스템 설계자"라는 두 가지 국가 전문 직위에 해당하는 두 단계로 나누어집니다. 이러한 분리의 결과는 "시스템 설계자"가 결과에 따라 시스템 설계를 수행해야 한다는 것입니다. 코딩은 나중에만 수행할 수 있으며, 그 과정에서 정보의 손실이나 왜곡이 있을 수 있으며, 실제 프로세스에서는 비즈니스 요구 사항이 변경됩니다(외부 환경의 변화나 비즈니스에 대한 더 깊은 이해로 인해 발생할 수 있음). ), 이로 인해 시스템 설계 및 프로젝트 요구 사항이 더 쉽게 분리됩니다. Eric Evans가 제안한 DDD 아이디어는 이 문제를 해결하는 것입니다.
2. 다양한 분야
도메인 모델은 시스템 기능 요구 사항의 핵심 도메인에서 비즈니스를 분석하는 비즈니스 분석 모델입니다. 소프트웨어 시스템은 구현하는 방법일 뿐입니다. 비즈니스보다는 비즈니스를 고려합니다. 일부(IaaS 서비스를 제공하는 회사 제외)는 시스템 설계라는 IT 분야의 문제를 고려하지 않습니다.
"도메인 모델"은 종합적인 분석 및 설계 모델입니다. 시스템 설계에 있어서는 시스템의 경계에 대해 생각해야 합니다. 따라서 이 모델의 분석 및 설계 분야는 다음과 같습니다. 사업분야와 IT분야의 결합.
호텔 예약 시스템을 컬럼으로 삼아 업무 내용을 설명하면 다음과 같습니다.
위 내용에는 사용자(user)와 회원(member)이라는 두 가지 개체가 포함됩니다.
비즈니스 분석을 한다면 설명의 첫 번째 문단에 있는 '사용자'가 관광객과 컨설턴트의 비즈니스 의미일 수도 있습니다.
시스템 설계를 고려하려는 경우 설명 첫 번째 단락의 "사용자"는 무시될 수 있습니다. 즉, 시스템 경계 내에 있지 않습니다.
3. 사용하는 단계와 포지션이 다릅니다
도메인 모델은 실제 프로젝트에서 시스템 분석가가 분석 단계에서 주로 사용하는 분석 모델입니다.
DDD의 '도메인 모델'은 종합적인 분석과 설계의 모델로, 실제 프로젝트에서는 분석과 설계의 두 단계에 걸쳐 '시스템 분석가'와 '시스템 설계자'의 종합적인 조합이 필요한 포지션이다. 능력.
4. 포함된 내용이 다릅니다.
도메인 모델의 주요 내용:
"도메인 모델"의 주요 내용:
도메인 모델 하위 이론 이론 학교는 비즈니스 범주에 속하며 소프트웨어 개발 범주에 속하지 않습니다. 이론 학교는 소프트웨어 개발 과정에서 무시되어야 하며 서로 혼동되어서는 안 됩니다.
실용주의자들은 도메인 모델이 복잡한 비즈니스 도메인 문제를 분석하고 이해하는 데 사용되는 분석 모델이라고 믿습니다. 특히 소프트웨어 개발 과정에서 시스템의 기능적 요구 사항을 충족하는 방법을 분석하는 것입니다. 분석 단계.
동시에 소프트웨어 개발 분야에는 DDD의 '도메인 모델'도 있습니다. 이는 시스템 설계와 설계 간의 연결에 중점을 둔 모델입니다. 수요 분석 및 시스템 요구 사항을 파악하고 시스템을 설계합니다. 수요와의 일관성이 향상되고 합리적인 수요 변화에 대한 확장성이 향상됩니다.