Pregunta

I'm struggling with the following domain design that seams not to fit within the concepts of DDD as I understand them.

In one hand, I have the Device->Sensor->Measurement hierarchy, modeled as an Aggregate with Device as as the root, Sensor as an Entity and Measurement as a VO. So far so good.

Now, each device has a type, as does the Sensor. At the same time Measurements refers to a variable been measured (e.g. temperature). Here is where things break apart.

I initially modeled types as Value Objects, but there's a limited set of types and many devices and sensors share the same types.

I then decided to model them as an aggregate, following a similar structure than the device aggregate: DeviceType->SensorType->Variable. However, this doesn't work as Sensors may reference to SensorType and Measurement to Variable, breaking the rule of only allowing references to the root of an aggregate from inside another aggregate. Besides, It may happen than more than one DeviceType includes the same type of sensor (e.g. a battery charge sensor) and also that more than one Sensor measures the same variable (e.g. battery charge level).

This leads me to having each of those entities (DeviceType, SensorType, Variable) as independent entities, each in its own (degenerated) .

My concrete question is: have I correctly interpreted the notions of Aggregate, Entity, VO or having such anemic aggregates with solely the root an anti-pattern?

¿Fue útil?

Solución

There are no hard and fast rules in modeling, you should do whatever fits your use case best. That being said, aggregates are mainly used for maintaining invariants across a group of entities. I don't see any such constraints between DeviceType, SensorType and Variable, hence I don't see any reason to put them into an aggregate. It should be fine to keep them as independent entities (or even value objects).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top