Domain Driven Design Aggregations

Question

This question is really about aggregations, NOT aggregation roots. Consider you have an entity for cars. the application displays a list (aggregations) of every "car level". for example the first level could be the car manufacturer.

like Audi, VW, ...

This list is an aggregation of my "car"-entity.

is there a good approach how to handle such "aggregated views" of an entity? is this an value object inside my domain?

Should i end up with 4 classes describing cars? this would be a lot of duplicated code? Or should i use the fully "Car"-entity for every level as representation but using a Interface to specify the fields you can access?

Answer 1

in Domain Driven Design, an aggregate is accessible only by it's root. an aggregate could be consist of entities and value objects. based on your needs you can have lot's of feature for your domain(they should not be persisted as an entity or value object). now in your example you can have Car entity (and also it could be the root of your aggregate) and have lot's feature for this entity, for example a car manufacture is obviously a value object.

Should i end up with 4 classes describing cars? this would be a lot of duplicated code? Or should i use the fully "Car"-entity for every level as representation but using a Interface to specify the fields you can access?

as I mentioned you can have lot's of enums, classes , interfaces to reduce the duplication of your code but remember that you should finally persist entity and value object. I advice you to separate the Car features such as Color, Manufacture, Model, ... and collaborate those features in your aggregate root to persist. it's better you to see some example about DDD in real world applications, take all of these samples and take a look at these articles.