0

私が理解しているように、DDDの概念に適合しない継ぎ目がある次のドメイン設計に苦労しています。

一方では、Device-> Sensor-> Measurement階層があり、ルートとしてDevice、エンティティとしてSensor、VOとしてMeasurementを使用したAggregateとしてモデル化されています。ここまでは順調ですね。

現在、センサーと同様に、各デバイスにはタイプがあります。同時に、測定値とは、測定された変数(温度など)を指します。ここで物事がバラバラになります。

最初は型を値オブジェクトとしてモデル化しましたが、型のセットは限られており、多くのデバイスとセンサーが同じ型を共有しています。

次に、デバイスの集合体と同様の構造に従って、それらを集合体としてモデル化することにしました:DeviceType->SensorType->Variable。ただし、SensorsがSensorTypeおよびMeasurement to Variableを参照する可能性があるため、これは機能せず、別のアグリゲート内からのアグリゲートのルートへの参照のみを許可するというルールに違反します。さらに、複数のDeviceTypeに同じタイプのセンサー(バッテリー充電センサーなど)が含まれている場合や、複数のセンサーが同じ変数(バッテリー充電レベルなど)を測定している場合もあります。

これにより、これらのエンティティ(DeviceType、SensorType、Variable)のそれぞれを、それぞれ独自の(縮退した)独立したエンティティとして持つことになります。

私の具体的な質問は、Aggregate、Entity、VOの概念を正しく解釈したか、またはルートのみがアンチパターンであるような貧血の集合体を持っているかということです。

4

1 に答える 1

0

モデリングには厳格なルールはありません。ユースケースに最適な方法を実行する必要があります。そうは言っても、集計は主にエンティティのグループ全体で不変条件を維持するために使用されます。DeviceType、SensorType、Variableの間にそのような制約は見当たらないので、それらを集約する理由は見当たりません。それらを独立したエンティティ(または値オブジェクト)として保持することは問題ありません。

于 2012-07-31T05:13:11.837 に答える