2010-04-01 3 views
4

저는 방금 사업에 "진정한 도메인 모델"을 제시하기 위해 수백만 달러의 비용을들이는 클라이언트를 위해 일을 마쳤습니다. 이것은 프로젝트의 유일한 산출물이었습니다.하나의 진정한 도메인 모델 - 오류?

이것에 대한 의견이 있습니까? 진실의 단일 버전이 현실적입니까?

+0

토론의 장소이므로 Community Wiki, IMHO –

답변

4

여기서 핵심 단어는 "모델"입니다. 모든 도메인 모델은 시스템의 모델의 키 엔티티 및 동작을 추상화 한 것입니다.

예를 들어 트래픽 관리 시스템에는 분할 할 수없는 엔티티 Car가있을 수 있습니다. 운전 시뮬레이션에는 구성 요소, 무게, 색상, 거주자 등 훨씬 더 많은 구조가 있습니다.

여기서 중요한 점은 자동차의 전체적인 정의가 없다는 점입니다. 특정 응용 프로그램 (또는 응용 프로그램의 일부)에 대해 신경을 쓰는 상태와 동작 만 있습니다.

3

아니요, 현실적이지 않습니다. 예, 오류입니다 ;-)

제 생각에는 재사용 가능성과 유지 보수성간에 잘 알려진 트레이드 오프입니다. 유지 보수성 측면에서 가장 중요한 측면이 있다면 종속성을 최소화하는 것입니다. 전체 비즈니스에 대한 '하나의 진정한 도메인 모델'은 분명히 엔지니어링에 상관없이 많은 의존성을 만듭니다.

나는 더 나은 유지 보수를 위해 갈 것입니다.

1

음, 도메인 모델. 모델링은 불필요한 세부 사항을 추상화 (생략)하는 실제 객체의 표현을 작성하는 추상화 기술입니다 (대개 중요한 측면을 미리 지정해야합니다). 도메인은 특정 비즈니스 영역입니다. 문제는 한 조직에서나 다른 관점에서도 도메인에 대한 다양한 견해가있을 수 있으므로 중요한 측면을 정의하고 모델링하기가 어렵다는 것입니다. 더 나쁜 문제는 시간이 지남에 따라 도메인과 시각이 바뀌므로 모델이 시간에 따라 바뀔 수 있다는 것입니다. 이는 비즈니스 민첩성에 관해 말할 때 중요합니다. 저는 개인적으로 도메인 모델이 특정 목적을 위해 사용해야 할 때 특히 유창하다고 생각합니다. 요구에 따라 주어진 목적을 위해 도메인의 현재 상태 및 뷰를 캡처하는 것이 더 좋습니다.

1

도움이되지 않는 한 가지는 모델링 언어를 지정하지 않는다는 것입니다.

아마도 데이터 모델은 관계형, ER, UML 클래스 또는 그와 비슷한 것입니다. 아마도 아닙니다. 어쨌든, 사용되는 언어가 모델에 어떤 종류의 정보가 있어야하고 어떻게 표현되어야하는지에 대한 합의가 이루어질만큼 충분히 명확하길 바란다. 명확한 의미가없는 다양한 유형의 모양과 장식으로 상자와 선을 그리면 좋은 모델을 얻을 수 없습니다.

내 투표에서 말한 것은 마커스의 대답입니다. 더 많은 정보를 포함할수록 더 끌고 가야합니다. 게다가 필요한 정보와 모델을 만드는 가장 좋은 방법은 필요한 정보, 정보를 얼마나 쉽고 안정적으로 얻을 수 있는지, 액세스 제어 고려 사항 (모두를 볼 수 있습니까?) 및 기타 고려 사항에 따라 다릅니다. . 이러한 요구 사항을 알지 못하고 미래에 어떻게 변할지 모르는 상태에서 완벽한 모델은 물론 좋은 모델은 없습니다. 물론 본질적인 품질 고려 사항이 있습니다 (예 : 당신이 그것을 매력적으로 만드는 특별한 요구 사항을 가지고 있지 않다면 정보의 중복 표현은 대개 나쁜 생각입니다.

기존 모델을 모델링하거나 재고하는 것이 시간 낭비는 아닙니다. 반대로 모델을 디자인하고 그 의미를 고려하면 기존 요구 사항이나 설계 제한 사항을 인식하는 경우가 많습니다. 일관된 표현을 위해 최선을 다해 모든 것을 가능한 한 단일 보편적 모델에 적합하게 만드는 것이 좋습니다. 그러나 그것은 확실히 모델링의 목표가 아닙니다.

아마도 비즈니스는 자신이 보유한 정보, 필요한 위치, 유지 관리 방법, 방법 및 모든 이점을 오래 동안 생각할 필요가있었습니다. 이 경우, 하나의 커다란 일관되고 완전한 보편적 정보 모델을 설계하는 목표를 설정하는 것이 좋은 방법이 될 수 있다고 생각합니다. 그러나 그 모델은 아마 주요 결과가 아닐 것이다.