2012-07-30 1 views
0

DDD의 개념에 맞지 않는 솔기가 나는 도메인 디자인에 어려움을 겪고 있습니다.두 개의 병렬 집계, 엔티티, 값 개체 계층 구조 모델링

한편으로는 장치 -> 센서 -> 측정 계층 구조가 있으며, 루트로는 장치와 함께 집합으로, 센서는 엔티티로, 측정은 VO로 모델링됩니다. 여태까지는 그런대로 잘됐다.

이제 각 장치에는 Sensor와 마찬가지로 유형이 있습니다. 동시에 측정 값은 측정 된 변수 (예 : 온도)를 나타냅니다. 여기에 상황이 깨지는 곳이 있습니다.

처음에는 유형을 값 객체로 모델링했지만 형식이 제한되어 있고 많은 장치와 센서가 동일한 유형을 공유합니다.

그런 다음 Device Aggregate : DeviceType-> SensorType-> Variable과 비슷한 구조에 따라 집계로 모델링하기로 결정했습니다. 그러나 센서가 SensorType 및 측정 값을 참조 할 수 있으므로 다른 집계 내부에서 집계의 루트에 대한 참조 만 허용하는 규칙을 위반하므로이 방법이 작동하지 않습니다. 게다가 하나 이상의 DeviceType이 동일한 유형의 센서 (예 : 배터리 충전 센서)를 포함하고 둘 이상의 센서가 동일한 변수 (예 : 배터리 충전 수준)를 측정하는 경우보다 발생할 수 있습니다.

이것은 각각의 엔티티 (DeviceType, SensorType, Variable)를 각각 자체 엔티티 (퇴화 된)로 갖는 데 도움이됩니다.

구체적인 질문은 : Aggregate, Entity, VO라는 개념을 올바르게 해석했거나 뿌리와 만만찮은 패턴을 가진 안티 패턴을 가지고 있습니까?

+0

내가 지금까지 가지고있는 코드 중 일부를 게시하면 도움이 될 것이라고 생각합니다. – eulerfx

+0

지금까지 코드가 없습니다. 나는 여전히 도메인을 모델링하고있다. 이미지를 제출하려고 시도했지만 시스템이 새로운 사용자 인 것처럼 허용하지 않았습니다. – pablochacin

+0

pablochacin, 도메인 모델링에 적합한 방법을 생각해 냈습니까? 비슷한 상황이 있습니다 ... – oakman

답변

0

모델링에는 엄격하고 빠른 규칙이 없으므로 유스 케이스에 가장 적합한 것이 무엇이든해야합니다. 즉, 집계는 주로 엔티티 그룹간에 불변량을 유지하는 데 사용됩니다. DeviceType, SensorType 및 Variable간에 이러한 제약 조건이 표시되지 않으므로이를 집계에 넣을 이유가 없습니다. 독립 엔터티 (또는 값 개체)로 유지하는 것이 좋습니다.

+0

DeviceType, SensorType 및 Varibale을 값 객체와 같이 모델링하지 않는 점은 일반적인 주소 예제와 같이 Device Sensor 및 Measurement (각각)의 단순한 속성이 아니라는 것입니다. 그것들은 한 번 시스템 구성의 일부로 정의 된 다음 다른 엔티티에 의해 참조됩니다. 그것이 저를 괴롭히는 것입니다. 당신이 지적했듯이, 아마 그들은 독립 엔터티로 취급되어야한다고 생각합니다. – pablochacin

+0

@pablochacin :이 경우 네, 엔티티로 모델링 할 수 있지만 엔티티로 유지할 수 있습니다. 집합체의 일부가 아닌 엔티티를 갖는 데는 아무런 문제가 없습니다. – casablanca